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ABSTRACT 


A systems  analysis  of  a comouter  system  to  suoport  the  STAR 
war  oaming  model  is  presented*  The  war  game  is  described 
and  the  user's  objectives  are  defined.  Four  conceptual 
methods  for  implementing  the  user's  objectives  are  oresented 

and  a preferred  solution  is  chosen*  The  characteristics  of 

✓ 

the  preferred  solution  that  are  necessary  to  meet  the  user's 
objectives  are  described*  Further  software  needed  to 
implement  the  objectives  is  briefly  discussed*  The  code  for 
the  current  model  is  analyzed  and  a summary  presented* 
Conclusions  from  this  systems  analysis  are  derived  and 
future  research  areas  are  identified* 
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I.  INTRODUCTION 


\ 
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A computer  simulation  is  the  representation  of  a 
mathematical  mode)  in  a manner  that  allows  the  user  to 
examine  the  system  beinq  modeled  and  gain  further  insight 
into  the  inner  workings  of  ^ the  system.  Typically^ 
simulations  fall  into  five  classes:  the  presentation  of 
unobservable  phenomenar  ooerator  training  models#  gaming 
models#  design  tools  and  models  of  systems  with  factors  that 
preclude  experimentation  on  the  system  itself  (Rahe  19721. 

Modern  computers  and  graphics  terminals  have  removed  the 
last  barriers  that  previously'  dictated  all-digital 
simulations.  These  terminals  can  be  used  as  exceptionally 
fast  and  versatile  output  devices.  The  computer  may  be 
equipped  with  a graphical  input  device  such  as  a graphic 
tablet  enabli/ig  the  system  to  be  used  as  a drafting  device 
with  unique  properties  (Newman  and  Sproull  19731, 

The  comouter  system  intended  for  use  should  provide  on- 
line# hands-on  high-speed  computation  with  excellent 
disolays  and  interfaces  to  externa)  hardware.  The 
application  of  graphical  support  to  war  gaming  adds  a 
dimension  previously  not  available  to  the  modeler.  The 
capability  to  visually  monitor  the  simulation  during 
execution  provides  insight  into  the  system  being  modeled 
that  tabular  results  obtained  after  the  fact  can  never  hope 
to  attain.  Interactive  programming  allows  the  develooment 


of  appHcations  Mhich  can  interact  with  a user  and  enable 
him  to  control  the  ' f unct i ons  oerformed  and  the  data  operated 
on  by  the  program.  The  modeler  may  now  interactively 
participate  in  the  simulation  and  at  critical  times  make 
decisions  that  will  create  changes  in  the  outcome  of  the 
simulation. 

One  important  facet  of  i nt  era'cM  ve  programming  is  the 
aspect  of  man^computer  symbiosis.  By  achieving  a very  close 
coupling  between  the  human  and  the  comouter»the  computer  may 
facilitate  formulative  thinking  and  allow  the  human  member 
of  the  partnership  to  participate  in  making  decisions  and 
controlling  complex  situations  without  inflexible  dependence 
on  predetermined  programs  [Licklider  19601. 

Any  system  dev'sed  to  attain  such  an  interactive 
simulation  system  with  graphical  support  should  not  be 
hastily  thrown  together.  "Add-on"  support  tends  to  overly 
complicate  and.  reduce  the  efficiency  of  the  existing  system. 
For  any  systemr  the  principles  of  simplicity  and 
effectiveness  are  essential  to  the  usefulness  of  the  system. 
These  two  principles  often  compete  with  each  other  (Smith 
1970J  . In  this  lightf  it  is  critical  that  to  support  any 
existing  or  planned  system#  a careful  systems  analysis  and 
design  must  be  the  first  step  toward  implementing  that 
support.  This  added  effort  should  result  in  an  efficient# 
effective  system  while  maintaining  maximum  flexibility  and 
simplicity.  In  the  rush  to  implement  a major  system#  the 
emphasis  is  generally  placed  on  the  application  with  little 


8 


111 


considerst ion  given  the  human  factors  when  the  interface 
between  man  and  his-  program  is  imolemented.  Human  interface 
is  desirabi'?  at  setup  time  when  there  are  many  displays# 
options  and  parameters  for  a user  to  control.  If  he  is  an 
experienced  user  he  does  not  want  to  be  forced  to  cycle 
through  aJl  the  options.  The  user  desires  only  enough 

promot i ng  information  to  change  those  options  necessary  to 

✓ 

setup  and  execute  his  run.  No  matter  how  weM  a system 
performs#  it  will  be  Httle  used  if  it  is  difficult  to 
setup.  The  user  must  be  considered  first  and  effective 
man-machine  interface  dialogue  will  . become  a major 
consideration#  as  *mportant  as  the  apoHcation  itself. 

The  process  of  extending  an  existing  war  game  to  include 
interactive  functions  is  so  complex  that  programming 
productivity  technigues  must  be  planned  and  employed  from 
the  onset.  These  modern  technigues  have  proven  to  be 
successful  in  control  of  software  projects.  Such  techniques 
as  structured  design#  top-down  design#  top-down  programming# 
modularization#  structured  programming  and  walkthroughs# 
chief  programmer  team  concepts  and  a scheduling  methodology 
will  be  crucial  to  the  development  and  maintenance  of  an 
acceptable  model. 

This  study  considers  all  possible  software  concepts  and 
explores  their  applicability  to  the  model.  Some  of  these 
that  could  prove  to  be  useful  tools  are:  database  management 
systems#  SIMSCRIPT#  graphic  support  languages  and  either 
general  puroose  or  tailored  versions  of  operating  systems. 
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Various  programming  languages  lend  themselves  to  war 


gaming*  The  advantages  of  a high  level  language  are  well 
established  and  their  usage  is  oarticularly  significant  in 
the  area  of  programmer  productivity.  Because  each  of  these 
language  instructions  translates  into  10*20  lines  of 
documented  code#  the  daily  productivity  of  the  programmer  is 
increased  at  least  three  fold*'  Jhis  increase  has  been 
demonstrated  in  numerous  studies  (Brooks  19751.  High  level 
languages  also  contribute  to  lower  application  maintenance 
costs#  improved  documentation  and  design  through  their 
ability  to  allow  se I f "document i ng  variable  names#  new 
constructs  and  easier  implementation  of  algorithms  (stack 
and  queue  manipulation  for  example) * 

SIMSCRIPT  is  an  example  of  a high  level  language 
especially  developed  for  simulations*  The  internal  functions 
of  SIMSCRIPT  such  as  the  event  scheduling#  queue 
manipulation  .and  system  defined  variables  enhance  the 
desirability  for  using  it.  FORTRAN  subroutines  can  be 
readily  called  from  the  language  allowing  program  efficiency 
to  increase  by  employing  critical  code  in  the  form  of 
fortran  subroutines*  The  current  version  of  SIMSCRIPT  11*5 
was  written  in  SIMSCRIPT  11*5*  This  fact  demonstrates  the 
versatility  of  the  language*  In  the  last  several  vears 
certain  developments  have  improved  the  efficiency  of 
SIMSCRIPT*  Among  these  developments  was  the  move  from  the 
generation  of  FORTRAN  intermediate  code  to  direct  generation 
of  machine  code.  Additionally#  the  number  of  steos  required 
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to  compeer  Hnk>ed{t  and  execute  a SIMSCRIPT  proQram  was 
reduced#  shortening  compilation  time* 

This  systems  analysis  parallels  most  systems  analysis 
procedures  but  addresses  the  question#  "What  resources  do  I 
need  to  provide  the  desired  capabilities  given  only  the 
constraint  of  using  SIMSCRIPT  11*5  as  a base  simulation 

language*  versus  "How  can  I design  this  system  to  run  on  a 

✓ 

particular  computer”.  This  is  considered  the  appropriate 
approach  to  designing  a system  which  truly  meets  the  neeos 
of  the  combat  modeling  community*  Figure  1*1  depicts  the 
systems  analysis  procedures  followed* 


unconstrained  systems  analysis  steps 


FIGURE  1*1 


The  first  end  key  element  of  this  systems  analysis  study 
was  the  identification  of  the  user's  objectives.  Without 
this  critical  action  the  entire  study  would  have  been 
meaningless.  The  objectives  fell  into  the  three  general 
areas  of  graphical  display  support#  simulation  of  the  battle 
area  and  the  capability  to  determine  the  status  of  the 
battle  or  any  of  the  components  o.f  the  battle  at  any  desired 
instant  of  time  during  the  simulation. 

Once  the  user's  objectives  were  determined#  the  next 
step  was  to  select  a set  of  general  performance  criteria. 
Performance  criteria  are  the  key  to  measuring  the  degree  of 
success  in  attaining  the  objectives  of  the  user.  System 
performance  measures  must  be  considered  to  oroduce  an 
efficient  and  effective  system  for  the  entire  life*cycle. 
The  system  must  possess  the  ability  to  reflect  changes  in 
both  friendly  and  enemy  force  structures  and  tactics.  The 
data  reflected  by  the  display  devices  must  be  current  at  the 
time  of  display.  This  could  mean  that  the  simulation  would 
have  to  be  halted  until  a signal  is  generated  by  the 
completion  of  the  display.  The  quality  of  the  data  base 
will  be  reflected  by  the  level  of  data  integrity  needed.  The 
size  of  the  data  base  must  be  such  that  only  necessary  data 
items  be  stored.  Any  abuse  of  this  will  surface  in  the 
response  time  for  any  display  invoked  and  the  overall  amount 
of  secondary  storage  required  for  the  data  base.  The  system 
was  designed  with  growth  in  mind  so  that  additional 
capabilities  may  be  accommodated  as  new  technology  develops. 
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As  tactics  snd  force  structures  changer  the  system  must  be  j 

( 

capable  of  easily  a.bsorbing  these  needed  changes.  Response 

time#  another  performance  measure#  is  considered  to  be  from 

the  time  a user  depresses  a carriage  return  after  a display 

request  until  that  request  is  satisfied.  From  other  studies  ^ 

(Sutherland  1R661  response  times  of  greater  than  10  seconds 

are  not  desirable  since  the  human. mind  will  become  impatient 

/ 

after  such  a long  waiting  period.  A good  response  time  is 
usually  three  to  five  seconds. 

Alternative  designs  were  conceived#  each  possessing  the 
capability  to  provide  all  of  the  desired  functions 

identified  as  user  objectives  within  the  oerformance 
criteria  established.  Alternative  conceptual  designs  are 
defined  as  concepts  arrived  at  through  "dreaming"  with  j 

objectives  and  restrictions  in  mind.  In  order  to  attempt  to  j 

capture  the  latest  hardware  and  software  capabilities  and  ] 

philosophys  and  incorporate  them  into  this  system#  a certain  * 

amount  of  general  research  was  conducted  in  the  areas  of 
simulation#  interactive  graphics#  database  design  and 
implementation#  operating  systems  and  systems  analysis  and 
design. 

After  the  list  of  designs  was  consolidated  into  general 
concepts#  each  conceptual  design  was  evaluated  to  insure 
that  the  design  under  consideration  met  the  objectives.  The 
advantages  and  disadvantages  of  each  alternative  were 
determined.  This  reduced  the  list  to  only  feasibile 

solutions  to  the  problem. 
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Chaoter  II  briafly  discusses  the  history  of  war  gaming^ 


the  evolution  of  . STAR#  a current  descriotion  of  STAR  and 
proposed  enhancements  with  the  support  required  to  achieve 
them.  This  final  version  of  STAR  is  the  entire  reason  for 
this  thesis#  that  is#  the  design  of  a system  to  reach  this 
goal  . 

Chapter  III  discusses  the  alternarive  approaches  to  the 

/ 

design  of  a support  system  for  STAR.  The  alternatives 
include  a database  management . system#  an  operating  system#  a 
distributed  system  and  graphical  routines  imbedoed  in  the 
simulation  program.  These  alternatives  are  described  and 
evaluated  as  to  their  individual  capability  to  implement  the 
system.  A prefered  solution  was  then  chosen. 

Chaoter  IV  continues  with  the  analysis  of  the  operating 
system  needed  to  support  the  solution  from  chapter  III.  The 
basic  features  needed  to  support  STAR  are  described  and 
examples  of  their  use  are  given.  The  modules  of  STAR  not 
previously  written  are  outlined  to  give  guidance  in  future 
development  activity. 

Chapter  V presents  the  results  of  the  analysis  of  the 


current  version  of  STAR.  This  chaoter  summarizes  the 


findings  of  the  analysis  and  presents  modifications  and 
r recommendations  that  will  lessen  the  storage  requirements 

I 

} “ for  STAR  while  speeding  up  the  execution  of  the  model. 


Chapter  VI  contains  conclusions  from  this  thesis  and 
recommends  further  courses  of  action  to  achieve  the  desired 
end  product. 


II. 


A.  history  of  mar  games 

M«r  games  are  nearly  as  old  as  organized  warfare  itself. 
Evidence  has  been  uncovered  that  indicates  the  use  of  games 
to  simulate  war  in  ancient  Egypt.  Progress  in  war  gaming  is 
marked  by  a series  of  improvements  in  support  techniques 
available  to  the  user. 

During  the  latter  half  of  the  eighteenth  century  the 
Prussians  developed  an  increased  emphasis  on  warfare  as  a 
branch  of  applied  mathematics.  In  1780«  Helwig#  Master  of 
the  Pages  for  the  Duke  of  Brunswick#  invented  a game  auite 
similar  to  the  modern  commercial  war  game.  The  game  used  a 
modified  chessboard.  Terrain  was  represented  by  using 
combinations  of  1666  small  squares  tinted  in  various  colors. 
These  small  Squares  were  grouped  onto  the  board  as  terrain 
features.  In  1795  Georg  Vinturinus  modified  the  game  by 
constructing  a map  board  of  an  actual  piece  of  terrain. 

In  1811  von  Reisswitz#  the  Prussian  Mar  Counselor  at 
Breslau#  transferred  the  war  game  to  a sand  table  with 
terrain  modeled  in  sand  to  a scale  of  1:2373.  In  1824  Army 
Lieutenant  von  Reisswitz#  Jr.  modified  his  father's  game  by 
transferring  the  game  to  a realistic  mao*like  chart  with  a 
scale  of  1:8000.  An  umpire#  detailed  rules#  and  probability 
tables  were  also  introduced  by  von  Reisswitz#  Jr.  The  size 
of  the  game  was  limited  to  approximately  four  square  miles 
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of  ground*  Tho  umoiro  not  only  monitored  the  play  of  the 
game  for  compliance  with  the  rules  but  also  imposed  two 
minute  time  slices  in  the  claying  of  the  game.  In  this 
manner  the  game  could  be  stopped#  as  desired#  and  a 
particular  two  minute  round  could  be  studied  in  detail. 

Further  improvements  occured  during  the  ninteenth 
century.  In  1866  Lieutenant  Nm,  McC.  Little  suggested  a 
game  called  "Naval  Mar  Game”  that  employed  blackboards# 
sheets  of  paper  or  charts#  or  maps  placed  on  tables  to 
illustrate  terrain.  At  about  this  same  time  celluloid  sheets 
or  overlays  were  introduced.  Information  drawn  on  these 
overlays  was  saved  as  a historical  record  that  could  be 
analyzed  at  a later  date.  This  idea  of  overlays  is 
attributed  to  the  Naval  Mar  College. 

Early  in  the  twentieth  century#  new  maps  prepared 
especially  for  map  maneuvers  showed  large  tracts  of  actual 
terrain.  The  oldest  map  of  American  terrain  made  expressly 
for  mao  maneuvers  dates  from  1906.  This  map  of  Fort 
Leavenworth#  Kansas  includes  a tract  approximately  four 
miles  in  width  by  six  miles  in  length  with  a scale  of  1:5280 
and  a contour  interval  of  ten  feet  (JCS  1969]. 

In  the  post  MM*II  era#  the  military  use  of  war  games 
became  increasingly  sophisticated  and  widespread. 
Sophistication  is  achieved  through  increasing  computer 
technology.  The  computer  allows  large  amounts  of  data  to  be 
stored  and  manipulated  without  tedious  bookkeeping  on  the 
part  of  the  user.  There  is  some  debate  over  the  usefulness 
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of  such  computer  simulations*  The  amount  0*1  data  generated 
is  so  great  that'  it  can  overwhelm  the  u8er»  thereby 
undermining  the  very  reason  for  the  simulation. 

Modern  computer  war  games  have  seen  evolution  similar  to 
manual  games*  One  parallel  development  is  in  the  terrain 
model  associated  with  the  game*  Early  games  used  flat 
(imaginary)  terrain*  Terrain  advanced  to  idealized#  easily 
constructed  models  that  represented  no  identifiable  terrain. 
The  next  step  was  to  represent  real  terrain  through  the  use 
of  digitization  at  the  expense  of  storage.  The  latest 
breekthrough  is  the  use  of  parametric  terrain  capable  of 
modeling  any  real  terrain  in  a size  never  before  imagined 
(Needles  1976] * 


B.  EVOLUTION  OF  SIMULATION  OF  TACTICAL  ALTERNATIVE  RESPONSES  j 

(STAR)  i 

A significant  effort  is  currently  underway  at  the  Naval  i 

Postgraduate  School  to  develop  a mi d^resol ut i on  combined  ' 

arms  model  to  determine  both  hardware  and  training  measures  j 

of  effectiveness.  One  of  the  primary  goals  of  the  model  is 
to  achieve  an  acceptable  level  of  resolution  while  assuring 
that  the  model  inputs  and  interactions  are  understood  by  the 

I 

military  dec i s i on>maker * 

Five  theses  completed  over  the  last  two  years  form  a 1 

basis  for  continuing  the  model  development.  A parametric  - 

terrain  model  was  developed  to  provide  a continuous  macro* 
terrain  representation.  This  representation  has  several 
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advantag**  ovar  tha  classical  approach  of  digitized  terrain. 
Li ne-of *si ght  computations  are  made  directly  from 
mathematical  relationships  as  opposed  to  the  time-consuming 
iterative  process  required  with  digital  terrain.  Mobility 
is  truly  continuously  as  opposed  to  piecewise  linear 
techniques  used  for  digitized  terrain.  Terrain  can  be 
considered  as  a parameter  of  the  combined  arms  analysis  as 
opposed  to  a given.  By  appropriate  selection  of  input 
parameters#  any  real  section  of  terrain  can  be  closely 
approximated  by  the  parametric  terrain  model.  Any  size 
terrain  sector  can  be  easily  generated  without  the  storage 
constraints  of  digital  terrain.  A dynamic  smoke  module  has 

I 

been  developed  and  operated  in  the  parametric  terrain  model. 

After  development  of  the  terrain  model#  two  theses  were 
devoted  to  a target  servicing  evaluation  of  blue  artillery 
against  a red  ground  threat.  The  result  of  this  effort  was  a 
working  model  programmed  in  SIMSCRIPT  which  provides  dynamic 
representation  of  the  artillery  missions  down  to  the 
individual  element  level.  This  model  forms  the  basis  for 
future  enhancements  of  the  combined  arms  model.  An 
ammunition  supply  model  was  developed  to  represent  the 
effects  of  such  parameters  as  interdictive  enemy  fire#  RAM- 
0#  truck  trips  per  day  to  the  ammunition  supply  point#  truck 
replenishment  rate#  etc.#  on  the  number  of  rounds  available 
to  the  combat  vehicles  over  any  sustained  combat  period. 

Current  efforts  are  underway  to  incorporate  two-sided 

ground  and  artillery#  with  other  systems  as  close  air 

# 
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support#  minefields# 


cannon  launched  guided  projectiles# 


advanced  attack  helicopters#  air  defense#  etc.  These 
enhancements  will  be  made  to  the  blue  battalion  versus  red 
regiment  model.  In  addition#  a dynamic  ammunition  resupply 
model  is  being  developed. 

C.  CURRENT  DESCRIPTION  OF  STAR 

The  structure  of  STAR  is  truly  hierarchial  in  that  it  is 
not  confined  to  any  specific  unit  size  or  configuration.  The 
parent-child  set  structure  of  SIMSCRIPT#  coupled  with  the 
flexible  parametric  terrain  model#  provides  the  required 
capabilities  to  realize  a hierarchial  representation.  The 
level  of  resolution  is  prescribed  by  the  requirements. 

The  first  study  application  of  STAR  was  in  support  of 
the  105/120mm  ammunition  stowed  load  requirements  for  the 
XM-l  tank.  Initial  production  runs  for  the  study  were 
conducted  for  a blue  battalion  versus  a red  regiment  in 
December  1978.  This  version  of  STAR  represented  all 
appropriate  ground  direct  fire  units#  two-sided  artillery# 
minefields  and  smoke.  Upon  completion  of  the  Phase  I 
bat tal i on— I evel  production  runs  (on  a 10  x 10  km 
battlefield)#  Phase  II  was  initiated.  The  result  of  Phase  II 
was  a brigade-level  model  versus  a red  division  on  a 
battlefield  approximately  50  x 50  km.  The  Phase  II  model 
will  be  capable  of  simulating  a mul t i -echel on  red  regimental 


i 

I 
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dynamic  play  of  ammunition  and  POL  resupply/  as  well  as  a | 

significant  enhancement  of  the  tactical  representation  of  ! 

battalion  engagements#  will  result  from  the  Phase  II  model.  ^ 

In  addition#  artillery  units  will  be  directly  represented  on 

1 

the  battlefield#  allowing  for  specific  play  of 
counterbattery  and  counter  air-defense  fires.  Finally#  a 
dynamic  air-to-air  defense  model'  )s  being  developed  for 
Phase  II  model  representing  two-sided  air-to-air  engaoements 
for  both  fixed  and  rotary  wing  aircraft.  All  appropriate  red 
and  blue  air  defense  systems  will  be  played  in  the  model. 

The  SIMSCRIPT  language  was  selected  for  STAR  because  the 
language  was  designed  for  discrete  event  simulations.  The 
many  embedded  features  of  the  language  give  the  programmer 
wide  latitude  in  the  construction  of  event  flow.  The 
language  is  English-like  with  regard  to  the  construction  of 
commands.  The  heart  of  the  embedded  .s i mu  1 at i on  facilities 
is  the  timeri  which  is  used  with  certain  structural 
characteristics:  entities#  attributes#  sets  and  events* 

These  facilities  greatly  simplify  the  process  of  writing  a 
simulation  program  and  debugging  the  code.  This  is  further 
enhanced  by  a compiler  which  provides  error  messages  and 
trace-back  routines  similar  to  WATFOR  and  WATFIV  id  FORTRAN. 

The  structure  of  STAR  begins  with  the  concept  of  an 
entity.  An  entity  is  simply  a representation  or  model  of  an 
item.  In  STAR  the  basic  entity  is  a weapon  system  | 

representing  tanks#  TOWS#  artillery  pieces#  etc.  Any  of 
these  entities  may  be  brought  into  existence  by  a simple 
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phraser  which  includes  the  name  of  the  entity*  For  example# 
the  phrase  CREATE  A TANK  reserves  a place  in  memory  for  the 
entity  and  its  attributes  which  the  programmer  has  chosen  to 
call  TANK*  Associated  with  the  word  TANK  is  a pointer 
variable  which  points  to  the  location  in  memory  where  TANK 
is  stored.  It  is  desirable  to  associate  certain 
characteristics  with  entities  after  they  have  been  created* 
These  characteristics  are  referred  to  as  attributes  and  are 
affixed  to  an  entity  by  the  internal  bookkeeping  procedures 
of  SIMSCRIPT  (the  system)  or  are  placed  on  the  entity  by  the 
programmer*  Attributes  must  be  changed  by  the  programmer  as 
necessary  to  reflect  changes  in  characteristics.  Moreover# 
the  system  will  change  system^def i ned  attributes  as 
necessary.  The  concept  of  sets  in  SIMSCRIPT  is  very  useful 
when  it  is  necessary  to  group  entities  based  on  certain 
characteristics  or  in  the  construction  of  queues*  In  STAR 
sets  have  been  used  primarily  to  portray  membership  in 
organizations.  The  set  structure  mirrors  organi zat i onal 
structure  and  enhances  the  programmer's  ability  to  model 
unit  tactics  from  a micro  to  macro  level.  An  entity  may 
belong  to  any  number  of  sets  and  the  entity  acquires  a 
membership  attribute  which  facilitates  identification  of  an 
entity's  unit* 

An  extremely  flexible  method  of  filing  allows  entities 
to  be  ordered  in  a set  by  ranking  of  certain  attributes  or 
by  a simple  f i rat»i n-f i rst-out  basis.  STAR  uses  the  latter 
system  for  most  applications*  The  set  logic  of  SIMSCRIPT 
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allows  this  to  be  easily  expanded  to  higher  level 
organizations. 

Each  entity  in  STAR  is  modeled  to  reflect  a flow  of 
activities  over  time.  In  oarticuiar^  each  entity  initiates 
or  undergoes  search#  detection#  target  selection#  firing  or 
impact.  These  five  events  are  scheduled  dynamically  based  on 
the  current  tactical  situation  or' ap  appropriate  probability 
distribution.  When  an  event  is  scheduled  for  an  entity#  the 
SIMSCRIPT  timer  makes  a record  of  the  time  that  the  event  is 
to  occur  (in  terms  of  overall  simulation  time)  and  the 
entity  for  which  the  event  has  been  scheduled.  Other 
characteristics  of  the  event  may  be  recorded  in  a manner 
similar  to  the  assignment  of  attributes.  At  the  appropriate 
simulation  time#  the  event  is  executed  unless  cancelled  by 
some  logic  provided  by  the  programmer.  This  event#  when 
created#  would  be  filed  in  an  event  set  which  contained# 
among  other  things#  the  time  that  the  event  is  to  take 
place#  the  entities  involved  in  the  event  and  the  event 
location  with  respect  to  other  scheduled  events.  When  X 
seconds  had  elaosed  from  the  current  simulated  time#  the 
event  would  take  place  and  the  consequences  of  the  logic 
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Event  routines  are  supoorted  by  a number  of 
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computational  subroutines  in  STAR.  Subroutines  are  written 


in  both  SIMSCRIPT  and  FORTRAN  which  has  given  the  simulation 
a great  deal  ot  flexibility.  The  difficult  1 i ne-of-s i ght 
calculations#  for  example#  are  accomplished  in  FORTRAN 
because  the  terrain  model  was  originally  written  in  FORTRAN. 
It  was  this  capability  to  call  FORTRAN  subroutines  that  made 
SIMSCRIPT  an  even  more  appeal  ing’  l^anguage.  Existing  FORTRAN 
routines  could  be  used  with  only  minor  modifications.  Other 
routines  more  closely  tied  to  the  entity  structure  of 
SIMSCRIPT  were  written  in  that  language.  The  routine  that 
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dimensioning  capabilities  of  the  language  and  the  pointer 
variable  link  listing  techniques  available.  For  large  target 
arrays#  these  language  features  are  extremely  efficient  in 
reducing  memory  requirements. 


D.  PROPOSED  ENHANCEMENTS 

The  STAR  combat  model  currently  under  development  at  the 
Naval  Postgraduate  School  operates  in  batch  mode  on  the  IBM 
360-67  computer  in  the  W.R.  Church  Computer  Center.  It  is 
difficult  to  build  a simulation  model  in  a batch  processing 
environment.  Batch  processing  consumes  much  of  the  time  in 
developing  the  simulation.  Interactive  simulation  is  more 
economical  as  well  as  more  effective  in  problem  analysis. 
One  of  the  primary  goals  of  this  project  is  to  expand  the 
model  to  operate  in  an  interactive  mode  with  graphical 
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support»  Figure  2.1  depicts  the  goats  of  this  project.  The 
modeler's  ability  tp  debug  a simulation  is  greatly  enhanced 
by  the  interactive  capabilities  of  a language.  Since  the 


simulation  user  is  constantly  engaged  in  upgrading  his 
simulationf  interactive  capabilities  are  an  important 
feature  of  any  support  system  (Mills  and  Phil  19771. 
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FIGURE  2.1 


The  ability  to  actively  particioate  in  this  war  game  in 


an  interactive  mode  would  contribute  to  both  the 
productivity  and  the  flexibility  of  the  model.  In  an 
interactive  environment#  the  player  or  modeler  would  be  able 
to  input  decisions  that  would  approximate  those  made  by  the 
commander  on  the  battlefield.  Through  this  man^computer 
symbiosis#  the  ability  of  the  model  to  more  accurately 


reflect  the  actual  outcome  of  a battle  would  be  attained. 
The  actual  flow  of  the  battle  could  be  altered  to  reflect 
realism  rather  than  rigid  programming  which  could  lead  to 


unforseen#  unrealistic  circumstances. 

A primary  concern  in  the  design  of  an  interactive 
simulation  system  should  be  ease  of  user  participation  in 
the  simulation  during  execution.  To  facilitate  this  ease  of 
use#  an  appropriate  interrupt  facility  is  necessary  to  allow 
for  suspension  of  the  orogram  at  a given  point  in  the 
program  logic  and  for  the  transfer  of  control  to  the  user. 
The  interrupt  handler  should  be  flexible  enough  to  process 
any  appropriate  reguest  at  any  time  and  return  control  to 
the  point  of  the  interruption  upon  completion  of  the 
handling  of  the  interrupt.  This  interrupt  facility  would  not 
only  allow  incut  to  the  model  and  output  from  the  model  but 
also  suspend  the  simulation  to  allow  detailed  examination# 
decision  making  and  synchron i ?at i on  between  simulation  time 
and  wall^clock  time. 


•ntirsly  critical*  In  modeling  terml nol ogy . real 't 1 me  is  In 
the  senae  of  wall^clock  time.  One  minute  of  clock  time 
constitutes  one  minute  of  simulation.  If  simulation  of  a 
thi rty~m1nute  battle  runs  in  thirty  minutes  of  wall  clock 
time,  the  simulation  is  said  to  run  in  real  time.  Real-time 
in  the  computer  science  vernacular  is  of  utmost  importance. 

A computer  system  is  said  to  be  -running  in  real-time  if 
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there  is  a computer  program  and  some  other  process  running 
"in-steo”  in  such  a way  that  the  associated  process  is  not 
caused  to  run  slower  by  the  computer  program.  This  could  be 
exemplified  by  the  simulation  program  and  the  graphics 
display  process*  If  the  simulation  program  sufficiently 
slows  the  Interactive  graphical  Input  process  that  the 
inputs  are  received  after  they  were  needed  for  use  in  the 
simulation,  then  the  computer  system  is  not  running  in 
real-time.  The  interactive  caoability  of  the  model  will  be 
useless  if  the ^inputs  are  not  entered  in  sufficient  time  to 
effect  the  outcome  of  the  battle.  It  is  this  real-time  that 
the  system  must  achl'eve. 

Facilities  are  needed  to  save  the  state  of  the  model  at 
any  time  by  executing  a single  command.  Conversely,  a 
command  should  be  available  to  restore  the  simulation  to  a 
previously  saved  state  and  execution  resumed  from  there. 
Such  a caoability  provides  the  ability  to  save  intermediate 
states  of  the  simulation  run  for  the  purpose  of  returning  to 
the  previous  points  in  simulation  time.  This  technique  is 
valuable  in  cases  where  an  unexpected  behavior  enters  the 
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simulation  or  an  important  behavior  was  bypassed  before  its  i 

presence  was  discovered  (Sohnie  1973J • f 

1 

Since  the  primary  purpose  of  the  game  is  to  function  as  j 

an  analytic  toolr  any  support  system  must  be  capable  of 
recording  all  interactive  decisions  for  use  in  duplication 
of  runs  with  alternate  modeling  parameters*  The  flow  of  the 

battle  should  also  be  recorded  in  'order  to  allow  in  depth 

✓ 

analysis  at  the  conclusion  of  the  simulation  run  if  desirea. 

There  has  been  little  imaginative  use  of  computer 
graphics  as  an  input/output  tool  for  simulations.  Some  use 
of  simple  plotting  has  been  used  but  the  power  of 
interactive  graphics  is  relatively  untouched.  Interfaces  to 
graphics  languages  will  permit  the  modeler  to  provide  more 
meaningful  displays  for  the  simulation  user.  Input  by  way 
of  graphics  has  been  grossly  underestimated.  Special 
purpose  graphics  input  is  a natural  means  of  getting  input 
with  today's  interactive  graphics  devices. 

The  most  fundamental  capability  of  the  proposed 
graphical  support  package  is  displaying  maos  of  the 
battlefield.  The  standard  mao  is  a 10  X 10km  contour  map. 

This  map  would  be  plotted  by  referencing  one  of  25  standard 
map  sections.  These  25  standard  map  sections  would  cover  the 
50  X SOkffl  battle  area.  By  selecting  one  of  the  numbers  from 
l“25f  the  appropriate  contour  map  would  be  drawn  using  the 
default  contour  interval  of  100  meters.  An  alternate  mode 
for  plotting  maps  would  be  provided  to  allow  the  plotting  of 
larger  areas.  Larger  maps  are  reguired  to  monitor  such 


27 


missions  ss  eounter^bst tery  fire  or  long  renge  surveillance. 
These  larger  plots' would  be  called  by  referencing  the  lower 
left  corner  and  the  upper  right  corner  utilizing  four  digit 
grid  coordinates.  Since  the  area  to  be  plotted  would  be 
larger  (or  smaller  if  so  desired)  a. contour  interval  must  be 
supplied.  Scaling  will  be  performed  as  a function  of 
maximum  and  minimum  grid  coordinates  specified. 

The  contour  maps  provided  are  the  background  for  several 
types  of  overlays.  These  overlays  may  be  selected  singly  or 
in  any  combination.  The  plotting  of  excessive  numbers  of 
overlays  may  lead  to  cluttering  of  the  display  screen  and 
should  be  avoided.  One  such  overlay  is  in  supoort  of  the 
dynamic  smoke  module  included  in  the  simulation.  The  smoke 
overlay  will  show  the  location  of  smoke  or  other  obscuring 
elements  such  as  fog  or  rain.  Density  of  the  smoke  is 
indicated  by  the  intensity  of  the  displayed  smoke.  As  the 
smoke  dissipates  the  intensity  decreases.  The  effect  of  wind 
on  the  smoke  is  shown  by  movement  of  the  smoke  display 
across  the  screen.  Results  of  patrols  and  reconnai sance 
flights  will  be  overlayed  on  the  basic  contour  map.  Targets 
detected  by  both  ground  and  aerial  observers  are  displayed 
while  under  observation.  The  results  of  active  ground 
detection  will  be  updated  as  required  by  moyement  of 
elements.  The  results  of  aerial  reconna i sance  are  static  in 
nature  after  the  completion  of  the  flight.  Other  oyerlays 
include  the  display  of  road  networks*  towns*  obstacles*  both 
natural  and  man  made*  animation  of  firing  events*  receipt  of 
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•nemy  firv#  nuclear  olanning  aids  and  indirect  fire 


Dynamic  route  and  position  selection  will  be  supported 
from  the  graphics  terminal.  By  utilizing  a light  pen^  data 
tablet#  cursor#  track  ball#  Joy  stick#  thumb  wheels  or  some 
other  type  input  device#  the  player  should  be  able  to 
interactively  input  changes  or  supplimental  information  into 
the  model  during  execution.  The  9raphical  support  package 
also  provides  for  the  monitoring  of  unit  movement  through 
the  use  of  periodic  updating  of  the  current  unit  position. 
During  execution  the  modeler  can  select  the  level  of  the 
unit  to  be  plotted.  If  the  modeler  selects  a unit  level 
other  than  individual  element#  the  plotting  of  the  unit  is 
performed  using  the  standard  military  symbol  for  the  unit. 

Dynamic  movement  on  the  battlefield  gives  additional 
realism  to  the  simulation  and  often  discloses  information 
that  words  cannot  convey.  Unit  movement  is  represented  as  it 
occurs.  The  .actual  firing  of  weapons  to  include  round 
flight  and  impact  enhance  the  picture.  Any  comoat  introduced 
visual  effects  such  as  smoke  from  exploding  rounds  is 
depicted  along  with  its  dissipation  and  drift.  One  of  the 
largest  benefits  of  displaying  unit  movement  is  having  a 
tool  to  debug  the  dynamic  route  selection  module  that  will 
be  developed  for  STAR.  Unless  the  modeler  has  the  capability 
to  monitor  the  route  taken  by  an  element#  he  can  never  be 
certain  of  the  performance  of  dynamic  route  selection  or 
where  that  element  is  located. 

Another  analytic  tool  to  be  furnished  the  modeler  is  the 
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ability  to  draw  1 in«*of *sight  (LOS)  fans.  These  LOS  fans  are 


f 
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used  to  aid  in  selection  of  positions  for  weapons  systems^ 
radars  and  other  LOS  dependent  systems.  Analytically#  these 
LOS  fans  serve  to  verify  LOS  calculations  for  firing  events. 

The  LOS  fan  will  be  represented  by  shading  on  the  contour 
map#  the  heavier  the  shading  the  greater  the  visability.  A 
second  type  of  LOS  fan  will  bg  offered#  this  being  a 
compliment  display  that  shades  the  area  that  cannot  be  seen. 

The  support  system  will  incorporate  an  inquiry 

capability.  Whenever  a simulation  creates  significant 

output#  thie  statistics  collection  capabilities  of  the 

simulation  language  may  not  provide  the  modeler  with  the 

information  needed.  Statistics  collection  by  a simulation 

language  is  often  too  general  and  if  more  aetail  is 

required#  a dump  of  the  state  changes  of  the  model  ^must  be 

analyzed.  This  inquiry  capability  supports  post  execution 

analytic  analysis  by  enabling  specific  information  to  be 

retrieved  and  thus  avoid  searching  volumes  of  data  to  obtain 

a single  data  item.  This  feature  of  the  war  game  allows  the 

various  players  from  staff  sections  to  inquire  and  receive 

• { 
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information  concerning  any  data  the  model  maintains  that  is 
normally  available  to  that  staff  member.  For  example  the 
G-l/S^l  needs  information  concerning  command  strength# 
losses#  individual  and  unit  replacements#  friendly  and  enemy 
prisoners  of  war  (ROW)#  civilian  personnel#  safety# 
personnel  services#  graves  registration#  casulty  reporting# 
awards  and  decorations#  medical  supply  and  maintenance# 
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straggler  disposition  and  headquarters  movements  security^ 
operation^  rear  command  post  location  and  visitors.  The 
is  concerned  with  recommending  essential  elements  of 
information  (EED#  requests  for  target  acqui  si  t i ons/ 
surveillance#  reconnai sance#  interrogation  of  enemy  POWs# 
debriefing#  captured  enemy  documents#  signal  intelligence# 
intelligence  interpretation#  weather#  predicting  NBC 
fallout#  situation  maos#  counterintelligence#  recommending 
proposed  areas  of  operations  to  the  6>3/S-3#  intelligence 
training#  aggressor  forces  if  employed#  civilian-military 
operations  and  camouflage.  The  G-3/S-3  is  tasked  with 
insuring  the  number  and  types  of  units  assigned  to  support 
and  accomplish  the  mission#  attachment  and  detachment  of 
units#  organising  and  eouiping  units#  training#  preparing 
the  operational  estimate#  integration  of  fire  and  maneuver# 
basic  and  special  loads  for  weapon  systems#  priorities  for 
allocating  critical  resources#  coordination  and  use  of 
airspace#  designation  of  bivouacing  areas#  recommending 
general  location  of  the  command  post#  electronic  warfare 
activities#  communications  and  maintaining  a current 
estimate  of  the  situation.  The  G-4/S-^  is  concerned  with 
matters  of  supply#  monitoring  the  distribution  of  supplies# 
supervising  the  distribution  of  critical  combat  weapons  and 
munitions#  recommending  prescribed  loads#  managing  special 
weapons#  procurement  and  storage  of  special  weapons# 
collection  and  disposal  of  excess  eguipment#  maintenance# 
repair  parts#  evacuation  or  retrograde  of  unservicable 
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•qu{pm«nt»  transportation#  refueling#  construction#  property 
control#  food  services#  use  of  ROMs  and  civilians  and 
decontamination  operations.  This  data  is  available  in  a 
tabular  form  similar  to  figure  2.2. 


TABULAR  DISPLAYS 
"INGRES  FLAVOR" 
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FIGURE  2.2 


The  graphics  paclcage  will  include  the  capability  to 
represent  terrain  in  three-dimensional  form.  This  facility 
enables  the  modeler  to  verify  that  the  shape  of  the  terrain 
used  in  the  model  is  in  reality  a true  representation  of  the 
actual  terrain.  Three-dimensional  terrain  plotting  also 
serves  to  verify  LOS  calculations  and  aids  in  selection  of 
routes  and  positions.  Through  the  use  of  three  dimensional 
terrain#  aircraft  flight  simulation  is  oossible.  The  viewing 
screen  is  capable  of  displaying  terrain  as  seen  from  an 
aircraft.  The  display  includes  the  terrain#  vegetation  and 


wtpwffwrai  ■'  


•11  •lemffnts  located  on  the  terrain  being  traversed. 
Additionally  this  ' three*dimensioned  terrain  feature  can  be 
expanded  to  provide  360  degree  scans  from  any  point  selected 


by  the  user. 

The  use  of  color  in  graphical  displays  was  determined  to 
be  of  extreme  importance.  The  representation  of  red  and  blue 
forces  is  an  obvious  advantage.  The^ability  to  use  color  to 
represent  vegetation  lends  realism  to  the  display.  The 
number  of  items  to  be  represented  is  so  large  thaft  without 
color  it  will  be  difficulty  if  not  imoossibley  to 
distinguish  features  displayed. 

A report  writer  is  of  practical  importance  to  the 
analyst.  This  report  writer  will  be  highly  formatted  to 
provide  statistics  required  by  the  analyst.  The  user  will  be 
able  to  specify  the  statistics  to  be  displayed  and  the  table 
will  be  generated  automatically.  Additional  hard  copy 
support  will  ,be  available  in  the  form  of  a copy  device 
attached  to  the  terminal  that  may  be  used  to  copy  the 
current  image  on  the  display  device. 

Any  graphical  support  system  devised  would  not  be 
complete  without  providing  assistance  to  the  user  during 
execution.  Instructions  for  use  must  be  availabley  on  cally 
at  any  timey  with  various  levels  of  detail  for  various 
levels  of  experience  in  playing  the  game.  This  type  of 
interactive  counseling  will  be  provided  in  the  form  of  a 
help  function...  This  help  function  will  be  provided  for  two 
levels  of  expertisey  the  novice  and  the  experienced.  The 
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novice  user  needs  Information  concerning  functions  j 

availabler  their  formats  and  their  commands.  The  expert/  on 

the  other  hand/  requires  only  a reference  to  the  commands  ' 

i 

available  since  he  is  familiar  with  their  formats.  { 

Certain  tutorials  and  guides  must  be  supplied  to  the 
user.  Directions  for  position  selection  using  the  line  of 
sight  fans  must  be  readily  available  for  use  during  setup  of 
the  simulation.  A military  symbol  library  should  be  , 

included  with  the  descriptions  of  the  available  symbols  and 


the  method  of  placement  of  the  symbol  of  the  overlay.  This 
description  includes  details  of  how  the  computer  decides 

where  the  automatically  generated  symbol  is  placed.  Any 

graphical  support  provided  for  this  system  must  provide  for  ^ 

an  interactive  means  with  which  the  user  can  generate  the 
parametric  terrain  and  verify  it  against  the  actual  terrain  j 

or  a map.  This  terrain  oackage  must  provide  not  only  ^ 

assistance  in  design  of  the  terrain/  but  also  the  capability  ^ 

to  record  the  parameters  selected  for  later  use  in  the 
simulation.  It  is  highly  desirable  that  the  user  have  the 
means  to  obtain  a hard  copy  of  this  terrain  generation  for 
this  verification  process. 

E.  types  of  graphical  displays 

The  graphical  support  package  will  consist  of  three 
separate  types  of  applications  packages.  The  first  type  of  { 

support  is  provided  in  the  form  of  monitors.  These  monitors  , 


Th*  terrain  plots  are  selected  by  the  user  and  displayed 


until  the  user  eiects  to  either  terminate  the  display  or 
request  another  sector.  The  display  monitor  reflects 
current  unit  movement  located  within  the  terrain  sector. 
The  user  has  limited  control  over  functions  of  these 
monitors.  These  monitors  have  the  basic  function  of 
displaying  the  contour  maps.  The  user  will  be  able  to  select 
from  a standard  set  of  10  X 10km  contour  macsr  or  he  may 
specify  a sector  using  grid  coordinates  and  the  desired 
contour  interval.  The  user  may  also  specify  the  unit  or 
element  to  be  displayed.  These  monitors  have  a selective 
zoom  feature  to  allow  the  user  to  focus  on  a given  area  in 
greater  detai I . 

A second  type  of  display  incorporates  the  inquiry  mode 
of  the  support  package.  These  displays  will  be  alpha* 
numeric  terminals.  These  terminals  enable  the  various  staff 
players  to  inquire  about  personnel#  logistical  and  other 
routine  affairs  of  a unit.  Levels  of  inquiry  are  controlled 
by  the  user.  The  terminal  initiates  a hierarchical  search 
with  the  highest  level  unit  available#  giving  the  ootion  of 
making  the  inquiry  at  this  level  of  resolution  or  displayina 
subordinate  units  at  a level  one  unit  lower.  If  the  user 
elects  to  make  his  inquiry#  then  action  is  initiated  to 
determine  the  type  inquiry  from  a menu  of  possible  choices. 
The  information  is  then  displayed  and  execution  continues. 
Should  the  user  elect  to  traverse  through  the  hierarchy  in  a 
downward  direction#  the  monitor  will  display  the  subordinate 
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units  snd  ask  the  user  to  indicate  the  unit  in  which  he  is 


j 


interested.  This  .is  continued  until  the  user  reaches  the 
level  he  desires  and  the  inquiry  is  initiated. 

A third  type  of  display  will  provide  the  function  of  the 
master  graphics  console.  This  console  is  fully  interactive 
and  accomplishes  all  dynamic  changes  and  selections  in  the 

program.  This  terminal  is  anticipated  to  be  larger  with 
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greater  resolution.  The  capability  for  drawing  in  three 
dimensions  is  realized  at  this  terminal.  All  graphical 
requests  are  originated  at  this  terminal  with  the  possible 
exception  of  the  inquiry  functions.  Inquiries  may  also  be 
initiated  at  the  alpha-numeric  terminals.  For  ease  in 
selection  of  the  function  to  be  perfopmed»  a menu  selection 
technique  is  used.  The  user  selects^  by  means  of  a light-oen 
or  some  curser  positioning  device#  the  desired  function  to 
be  performed.  This  initial  selection  leads  to  the 
fullfillment  of  the  user’s  request  or  the  display  of  another 
menu.  In  addition  to  providing  the  executive  routine  which 
manages  the  execution  of  the  simulation#  the  monitor 
provides  the  ability  for  the  user  to  interact  with  the 
simulation  program  directly  from  the  terminal.  This  allows 
the  user  to  not  only  observe#  verify  and  record  data#  but 
also  interrupt  the  simulation  to  change  parameter  values  or 
modify  the  model  structure.  Figure  2.3  depicts  types  of 
di spl ays . 


FIGURE  2.3 
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IM.  CONCEPTUAL  SOLUTIONS 


The  problem  at  hand  is  to  implement  graphical  support 


and  inquiry  capability  to  an  existing  war  game  without 


serious  degradation  of  performance.  This  problem  is 


generated  by  the  merging  of  several  capabilities.  These 


capabilities  include  maintaining  a real  time  environment 


sharing  of  common  data  items  without  data  redundancy^ 


process  synchronizationr  accurate  and  timely  displays  and 


interactive  participation  by  both  the  user  and  programs 


The  puzzle  is  to  fit  these  areas  into  a complete  picture 


problem  has  been  simplified  by  one  assumption.  The  type  of 


computer  utilized  is  irrelevent  providing  it  is  capable  of 


performing  to  the  specified  standards.  The  question  of 


mini^  maxi  or  micro  implementation  revolves  around  the  state 


purpose 


computing  system  itself.  If  this  simulation  system  is  to 


become  highly  portabler  then  the  preferred  choice  may  be  a 


microcomputer  due  to  its  low  cost  and  portability.  If  this 


stand-alone 


system#  then.it  may  be  appropriate  to  develop  the  system  on 


a minicomputer.  If  this  simulation  system  is  to  share  time 


with  other  programs  in  a multiprogramming  environment#  then 


the  appropriate  choice  may  be  a large  mainframe  capable  of 
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leaves  machine  choice  to  the  individual  implementer. 

Solutions  to  thO  puzzle  fall  into  four  general  classes 
with  various  degrees  of  difficulty  and  performance 
standards.  These  choices  include  a database  management 
system^  a tailored  operating  systemr  a distributed  system 
and  graphic  subroutines  embedded  within  the  simulation 
itself.  Brief  descriptions  of  the  characteri st i cs  of  these 
four  approaches  are  discussed  in  the  next  four  sections. 
Section  E evaluates  each  approach's  ability  to  implement  the 
simulation  system.  The  preferred  solution  is  chosen  in 
Section  F. 
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A.  DATABASE  MANAGEMENT  SYSTEM 


One  approach  to 

the 

problem  of  supolyi 

ng 

graphical 

support  to 

the  STAR 

model  is  through  the  use 

of 

a database 

management 

system. 

A 

database  management 

sys 

tern  is  a 

collection 

of  software 

procedures^  designed 

to 

f ac i 1 i tate 

access  to  a data  base.  This  data  base  is  shared  by  diverse 
users.  In  this  approach  the  main  simulation  program^ 
written  in  SIMSCRIPT»  would  act  as  a high-level  language 
applications  program.  The  user  would  interface  with  the 
applications  program  through  the  use  of  any  standard 
alphanumeric  terminal.  The  graphics  routines  would  act  as 
other  high-level  language  applications  programs.  Since  a 
database  management  system  has  the  property  of  being  able  to 
present  the  same  data  to  various  users  in  differing  formats^ 
the  applications  programmers  would  have  their  own  external 
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models  of  the  data  available  to  them  (Curtice  1976).  This 
differing  view  would  allow  the  graphics  programs  to  be 

i 

written  in  some  language  other  than  SIMSCRIPT  since  at  this  I 

time  there  is  no  provision  for  graphical  support  in 

SIMSCRIPT.  • 

4 

The  actual  data  that  is  being  manipulated  by  the  { 

applications  program  is  stored  fn^a  common  area  within  the 
computer  system.  The  function  of  the  database  management  i 

system  is  to  allow  the  sharing  of  the  data  and  create  data  ! j 

independence  to  allow  for  different  views  of  the  data.  It 
is  the  responsibility  of  the  database  administrator  to 
develop  and  maintain  the  schemas  allowing  this  mapping  to 
occur  (Martin  19761. 

Database  management  systems  must  interface  with  the 


operating  system  in  order  to  accomplish  the  actual  mapping 
of  data  into  memory.  The  operating  system  and  the  database 
management  system  must  coexists  but  this  does  not 
necessarily  1-imit  the  usage  of  a database  management  system. 
Operating  systems  are  available  under  which  any  given 
database  management  system  may  operate.  There  is  an 
important  relationship  that  must  be  discussed.  Database 
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support » Input  and  output  support  and  usaqa  measurament 


(Wiadarhold  19771  .'  Sons  oparating  systams  also  provida 
faciHtias  for  sharing  of  data  sagaants  (Organik  19721. 

Tha  usa  of  a databasa  managamant  systam  has  savaral 
advantaqas.  Tha  databasa  managamant  systam  supports  multipla 
usars  of  tha  systam  at  any  givan  tima.  Data  radundancy  is 
raducad  if  not  aliminatad.  AopTi^ations  programs  ara  data 
indapandant.  Tha  databasa  managamant  systam  providas 
intarnal  safaguards  for  data  intagrity  [Data  19771.  Post- 
axacution  analysis  is  also  facilitatad.  Tha  ability  of  a 
usar  to  conduct  inquirias  is  simplifiad  by  tha  adoption  of  a 
highly  tailorad  data  manioulation  lanquaga. 

A databasa  managamant  systam  offers  a broad  range  of 
facilities  for  organizing^  viewing  and  manipulatina 
information.  The  creation  of  data  tables  by  tha  user 
requires  only  a minimum  knowladqe  of  the  systam.  Often  new 
tables  can  be  gonstructed  automatically  from  existing  tables 
on  tha  basis  of  soma  format  property  of  the  original  table 
[Pram  at.al.  19771  . 

Typical lyr  data  manipulation  languages  are  written  in 
English»1ika  commands.  Mith  minimal  training*  a novice  user 
can  do  useful  work  on  the  databasa  management  system  using 
tha  data  manipulation  language.  Many  of  tha  more  common 
commands  may  be  invoked  in  a dialog  form  in  which  tha  system 
prompts  tha  usar  for  additional  data  or  instructions. 

One  of  tha  largest  disadvantages  is  the  addition  of  more 
overhead  and  hence  additional  execution  time.  Part  of  this 
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probem  may  ba  overcome  by  the  design  of  a compiled  database 
management  system  i nstead  of  an  interpreted  one  [hiederhold 
19771.  In  a typical  database  management  system^  a single 
user  command  may  result  in  the  performance  , of  several 
physical  input  or  output  operations.  Each  input  or  output 
operation  must  be  initiated  by  the  central  processor  unit. 
In  a multiprocessing  env i ronment /* t h i s requires  the  seizing 
and  releasing  of  the  central  processor  unit  several  times  to 
carry  out  a user  commands  therefore  a significant  overhead 
due  to  task  switching  may  be  accrued.  The  order  of 
increased  complexity  introduced  to  the  system  by  the 
database  management  system  concept  must  be  considered. 
Database  management  systems  are  considered  by  many  to  be  as 
complex  as  some  operating  systems  and  hence  introduce  an 
additional  complexity  factor  over  and  beyond  the  operating 
system  and  the  basic  application  programs.  Figures  3.1~3.2 
diagrams  the  rpl 1 of  a Database  Management  System. 
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B.  OPERATING  SYSTEM 

Modern  computer  hardware  is  very  powerful  and  may  be 
used  for  a variety  of  tasks.  The  hardware  machine  is 
difficult  and  awkward  to  use.  In  order  to  simplify  usage  of 
the  bare  computer^  ooerating  systems  have  been  developed  to 
provide  a more  hospitable  interface  with  users.  Operating 
systems  have  become  so  essential  to  efficient  computer 
operation  that  many  peoole  view  them  as  inseparable  from  the 
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hardware  {Madnick  and  Donovan  197a] . 

An  operating  system  is  a collection  of  software  modules 
within  the  computer  system  that  control  the  operation  of  the 
computer.  These  modules  simplify  the  use  of  the  system# 
attempt  to  optimize  performance  and  resolve  conflicts  within 
the  system.  The  modules  manage  the  processors#  main 

storage#  secondary  storage#  input/output  devices  and  files. 

✓ 

The  operating  system  performs  the  task  of  scheduling  the  use 
of  the  computer.  Sophisticated  operating  systems  increase 
the  efficiency  and  subsequently  decrease  the  cost  of  using  a 
computer. 

Operating  systems  vary  in  complexity  from  simple  monitor 
systems  on  microcomputers  to  sophisticated  large  scale 
systems  capable  of  multiprogramming  and  multiprocessing 
while  providing  protection  and  interrupt  hardware. 
Regardless  of  the  complexity  of  Che  system#  all  operating 
systems  provide  binding  for  processors  and  memories.  The 
operating  system  binds  data  to  physical  memory  locations  and 
output  files  to  output  devices.  A process  is  bound  to  a 
processor.  The  ability  to  perform  binding  is  fundamental  to 
all  operating  systems. 

Operating  systems  are  somewhat  distinct  in  their  ability 
to  provide  protection  mechanisms  [Graham  and  Denning  1972]. 
The  first  level  of  protection  provided  by  operating  systems 
is  common  to  all  reliable  systems.  This  is  the  protection 
of  the  operating  system  itself  from  destruction  by  tampering 
due  to  the  executing  program.  This  tampering  may  be 
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accidental  due  to  the  miscalculation  of  a subscriot  or  some 
similar  mistake/  or  it  may  be  an  intentional  effort  to 
sabatoge  the  system.  Mhatever  the  source  of  the  tampering/ 
the  operating  system  must  protect  itself.  A significant 
difference  in  operating  systems  is  the  ability  to  protect 
classified  data  within  the  computer  system.  Some  computer 
systems  are  secure  only  in  the  dedicated  mode  where  only 
classified  material  is  allowed  in  the  computer  and  the 
security  perimeter  is  external  to  the  machine.  A more 
complicated  but  more  useful  type  of  security  is  the 
multilevel  mode.  In  the  multilevel  mode  the  system  may  have 
various  users  with  varying  levels  of  security 
classification/  all  competing  for  system  resources 
simultaneously  [Whitmore  et.al.  19731.  The  security 
perimeter  is  internal  to  the  computer  and  provided  by  a 
mechanism  of  the  operating  system.  Access  permission  is 
determined  by  the  operating  system.  This  security  mechanism 
may  implement  a descret i onary  or  nondescret i onary  policy. 


Some  operating  systems  are  capable  of  mu  1 1 i programmi ng. 
In  a multiprogramming  environment/  several  user  programs  are 
allowed  to  compete  for  system  resources  simultaneously 
[Dennis  1965J . It  is  the  function  of  the  operating  system 
to  decide  which  job  will  be  run  at  any  given  time.  It  may 
be  possible  for  the  user  to  define  the  priority  of  the  job 
to  the  operating  system.  If  this  is  the  case  the  operating 
system  does  not  have  the  problem  of  enforcing  a 
descret i onary  priority  policy.  Determination  of  the 


priority  m«y  be  left  to  the  operating  .system.  Operating 


Methods  include  estimated  length  of  execution#  estimated 


storage  regui rements#  estimated  execution  time  and  estimated 


An  operating  system  may  also  use  a 


output  1 i nes 


combination  of  these  two  techniques.  It  is  left  up  to  the 


operating  system  to  limit  the  number  of  programs  the  system 


Some  operating  systems  allow  multiprocessing  (Smith 


19771.  In  a multiprocessing  environment  the  computer  system 


has  multiple  processors#  each  capable  of  independent 


It  is  the  responsibility  of  the  central 


operat i on 


processor  unit  (CPU)  to  coordinate  or  synchronize  the 


functioning  of  the  processors.  In  a system  such  as  this  it 


one 


calculations  while  another  processor  is  controlling  output 


The  operating  system  not  only  provides  memorv  rsnagement 


in  the  form  of  binding  but  also  is  capable:  af  creating 


the  program  being  executed  to  be  either  greater  than  or  less 


size  of  the  main  memory  (Denning  19701 


Another  feature  of  operating  systems  is  their  ability  to 


handle  interrupts.  Through  the  use  of  an  interrupt  handler# 


the  operating  system  may  accept  an  interrupt#  process  it 


1 


according  to  the  instructions  in  the  interrupt  handler  and 
return  execution  to- the  program  in  progress  at  the  point  of 

I 

t the  interrupt.  Operating  systems  have  system  defined 

[ interrupt  handlers  but  many  have  provisions  for  the  user  to 

define  his  own  interrupt  handlers. 


C.  DISTRIBUTED  SYSTEM 

A distributed  system  is  a computer  system  composed  of 
multiple  central  processors  that  cooperate  in  problem 
solving.  These  CPU's  may  be  spread  over  many  miles  or 
located  in  the  same  room.  In  order  for  the  distributed 
system  to  function#  coordination  between  the  processors  is 
accomplished  by  a distributed  ooerating  system. 

The  problem  of  extending  the  execution  time  of  the  model 
might  be  alleviated  by  tbs'  concept  of  a distributed 
computing  system  composed  of  one  computer  to  process  the 
simulation  portion  and  maintain  a master  data  base  and  a 
smaller  computer  providing  the  graphics  and  inouiry 
capabilities.  A distributed  system  has  the  chacteristic 
that  the  functions  are  distributed  or  spread  over  multiple 
CPU's  each  designated  to  handle  a particular  function.  This 
approach  becomes  advantageous  by  using  a second  processor  to 
reduce  the  work  load  of  the  main  CPU.  Consider  the  case  of 
a front-end  processor  connected  to  a main  processor  as 
indicated  by  figure  3.3. 
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DISTRIBUTED  SYSTEM 


FIGURE  3.3 


The  front>end  processor  controls  the  interface  with  the 
user.  Graphical  displays  and  user  command  interpretation 
including  editing  are  performed  on  the  front*end  processor. 
This  allows  the  power  of  the  main  processor  to  be  devoted  to 
the  computation  bound  simulation  functions.  In  this  case 
the  main  processor  would  have  to  pass  the  required  display 
; data  to  the  graphics  processor  as  needed.  Assuming  that 

this  would  take  a small  amount  of  time  under  CPU  to  CPU 

t 

communication  with  a communication  line  of  high  transfer 
rate  equal  to  the  slower  rate  of  the  two  processors^  the 

ad 
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main  processor  could  continue  to  simulate  while  the  graphics 
processor  generates  the  display  list  and  causes  the  display 
to  occur.  This  would  have  the  effect  of  halting  the 
simulation  for  only  a minimum  time  frame  and  thereby  not 
significantly  degrade  the  system.  Should  it  be  desirable  to 
stop  the  simulation  for  some  update  of  information  from  the 

graohics  processor#  an  interrupt  could  be  generated  by  the 

/ 

graohics  processor  and  sent  to  the  main  processor  which 
would  then  halt  the  simulation  to  receive  the  update.  The 
problem  of  maintaining  data  integrity  emerges  from  the 
aforementioned  situation.  There  is  no  way  to  determine  if 
the  data  to  be  changed  exists  at  the  time  of  update  or  if 
the  data  displayed  is  current.  This  problem  will  have  to  be 
resolved  by  generating  an  update  request#  displaying  the 
current  status  of  the  battle  area  and  then  updating  the 
data.  This  must  be  handled  through  some  automated  means  so 
that  the  user  is  not  confronted  with  the  problem#  he  has 
enough  to  be  concerned  with  without  the  system  comolicating 
the  situation  for  him. 

The  distributed  system  functions  as  follows.  First  there 
must  be  established  priorities  that  each  CPU  follows.  For 
instance#  on  the  simulation  CPU#  communication  between  CPU's 
has  a higher  priority  than  the  simulation  and  can  be 


represented  by 

the 

f o1 lowing 

pseudo 

code# "while 

(not 

commun i cat i ng) 

do 

simulation" 

. This 

action  will 

gi  ve 

priority  to  CPU-CPU  communication#  allowing  the  user's 
inquiries  to  be  answered  more  rapidly.  The  graphics  CPU 


I 


I 

* 


1 


i! 


] 
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continuously  tests  the  terminals  for  the  indicator  that  the 
user  desires  to  perform  some  function.  This  can  be  also 
accomplished  through  an  interrupt  mechanism.  Upon 
identification  of  the  user's  desired  function^  an  argument 
list  is  constructed  in  conjunction  with  additional  user 
supplied  data^  if  required^  and  an  interrupt  is  generated  to 
the  simulation  CPU  indicating  that  the  graphics  CPU  desires 
to  communicate.  Upon  receipt  of  the  argument  list  the 
simulation  CPU  stops  the  simulation^  stores  the  machine 
state  and  executes  a "case"  structure  similiar  to: 

swi tch ( f unct i on-id); 

{ 

case(t):  terrain  information; 
case ( i ) : i nqu i ry ; 
case(u):  update; 

• 

> 

passing  back  to  the  graphics  CPU  any  resulting  information. 
The  graphics  CPU  now  processes  the  information  received  from 
the  host  CPU  and  continues  the  function  originally 
identified  by  the  userr  such  as  producing  a display. 


0.  EMBEDDED  GRAPHICS 

The  simplest  and  perhaps  the  most  direct  implementation 
of  the  desired  capabilities  is  the  execution  of  the  graphic 
capability  from  a direct  subroutine  call  from  the  SIMSCRIPT 
simulation  program.  Figure  3.^1  depicts  the  embedded  graphics 
approach . 
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There  are  several  advantages  to  this  approach.  The  graohics 
package  can  be  developed  separately  from  the  simulation 
models  keeping  in  mind  that  necessary  parameters  required  by 
the  display  must  be  passed  from  the  simulation  program  to 
the  graphics  subroutine.  A simple  driver  could  minic  the 
functions  of  the  call  to  the  graphics  routine  during  the 
development  of  the  graphics  package.  In  the  same  wayr 
should  the  graphics  subroutine  provide  the  interface  with 
the  user  for  the  interactive  portions  of  the  models  certain 
parameters  would  have  to  be  returned  to  the  simulation 
program.  These  parameters  must  define  the  type  of  function 
that  the  user  desires  to  perform  along  with  any  function 
parameters  required.  The  values  of  the  parameters  could  be 
established  through  interpretation  of  light  pen  input  from 
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the  user.  This  interpretat f on  could  take  the  form  of  a CASE  I 

I 

or  nested  IF  type  structure  where  parameter  values  would  be 

i 

established  from  an  interpretation  or  series  of  ! 

interpretations  of  the  light  pen  input.  Once  the  parameter 

t 

list  is  formed  the  graphics  subroutine  is  called. 

There  are  disadvantages  to  this  concept.  Due  to  the 

nature  of  subroutine  calls#  the  action  of  the  simulation 

/ 

program  is  at  a standstill  until  the  execution  of  the  call 

I 

is  completed.  This  will  increase  the  execution  time  of  the  | 

simulation  program  and  thereby  increase  the  wall^clock  time 
required  to  simulate  any  given  battle.  This  problem  ceases 
to  retain  great  importance  if  it  is  desirable  that  the 
simulation  be  halted  to  allow  any  update  information  to  be 
passed  to  the  simulation  process  and  thus  maintain  data 
integrity.  I 

Because  data  integrity  is  a requirement  of  the  system# 
the  graphical,  displays  must  be  capable  of  depicting  the 
exact  state  of  the  simulation  upon  the  display  device.  To 
change  the  route  of  march  of  a particular  unit  or  element 
that  item  must  be  located  in  the  depicted  position  at  the 
time  of  the  update  or  the  exact  position  must  be  known  to 
( the  user. 

E.  EVALUATION  OF  ALTERNATIVES  = 

1.  Common  Considerations  ; 

There  are  several  items  that  are  common  to  all 
I approaches.  Included  in  these  items  are  the  use  of  color 
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displays#  hard  copy  devices  and  the  treatment  of  static  data 


such  as  contour  maps.  Hard  copy  devices  are  required  to 
record  selective  displays  upon  command  of  the  user.  Contour 
maps  are  thought  of  as  any  required  data  to  enable  a rapid 
draw  of  the  desired  area  of  terrain.  Once  the  parametric 
terrain  data  is  constructed*  prior  to  the  simulation 
execution  and  during  some  system  1,n1 1 1 all  zat  1 on  procedures# 
there  Is  no  need  for  the  simulation  process  to  have  access 
to  It  since  the  simulation  routines  compute  any  required 
terrain  data  dynamically  during  execution.  There  Is  only  the 
need  to  have  this  data  available  to  the  graphics  display 
routines.  The  Impact  of  a hard  copy  device  upon  the 
solution  Is  seen  as  device  dependent  and  therefore  not  of 
concern  In  the  selection  process.  In  the  same  manner  the 
method  of  drawing  contour  maps  Is  device  dependent  and  the 
use  of  color  is  Independent  of  Implementation.  These  two 
factors  are  also  omitted  from  the  evaluation  process.  This 
evaluation  focuses  on  the  ability  or  Inability  of  the 
alternative  to  support  the  simulation#  evaluating  failures 
on  the  lowest  possible  level. 

2.  Database  Management  System 

In  the  database  management  system  approach#  the 
simulation  program  assumes  the  role  of  a h1gh*level  language 
applications  program.  All  graphical  routines  except  the 
Inquiry  program  are  also  high-level  applications  programs. 
The  inquiry  program  Is  an  applications  program  written  In  a 
tailored  data  manipulation  language. 


sa 


I 


1 

A database  management  system  is  designed  to  allow  the  I 

sharing  of  data  and. el i mi nate  data  duplication.  Through  the  | 

design  of  appropriate  schemasr  the  database  designer  is  able 
to  present  each  apolications  programmer  with  an  independent 
view  of  the  data  and  allow  the  orogrammer  to  access  any  data 
within  the  data  base.  This  aoproach  presents  a problem  with 

multiple  users  attempting  to  write  data  simultaneously. 
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This  problem  can  Oe  minimized  through  careful  design  and 
judiciously  granting  write  access  to  shared  data.  Should 
two  users  desire  to  write  data  to  the  same  filer  the  last 
copy  written  will  prevail. 

The  recording  of  dynamic  events  presents  a 
significant  problem  to  the  database  management  system 
approach.  The  ability  of  the  system  to  accept  and  store 
input,  data  from  the  user  is  routine  to  a database  system. 

Anything  that  can  be  input  and  stored  may  also  be  recorded 
on  secondary  storage  media.  The  significant  problem  arises 
when  the  machine  state  must  be  saved.  Only  the  operating 
system  has  the  capability  to  monitor  and  modify  all  the 
registers  in  the  machine.  For  the  database  management 
system  to  save  the  machine  stater  close  cooperation  with  the 
operating  system  is  reguired.  When  it  is  desired  to  return 
to  a decision  point  to  resume  execution  with  another 
decisionr  the  database  management  system  must  relinguish 
control  to  the  operating  system  while  the  operating  system 
restores  the  values  of  the  variables  and  the  machine  state. 

Flexibility  of  play  will  reguire 

S5 


the 


database 


manag«m«nt  system  to  maintain  some  mechanism  to  generate  the  f 

appropriate  data  structure  for  the  leve)  of  play.  The  j 

fiexibility  of  play  is  not  an  insurmountable  problem  but  the 
mechanism  to  achieve  this  goal  may  be  quite  complicated.  I 

The  flexibility  of  display  wilt  be  quite  easily  attained  j 

since  display  is  dependent  only  on  the  data  stored  once  the  | 

data  structure  for  storing  the  data  has  been  created.  The 

/ 

ability  to  store  various  force  structures  must  also  be 
attained  by  some  dynamic  means  since  the  actual  size  of  the 
data  structure  required  will  not  be  known  until  run  time. 

The  degree  of  interactive  programming  attained  by  the 
database  management  system  will  vary  from  routine  to 
routine.  The  inquiry  routines  will  have  the  full 
interactive  characteristics  of  any  database  management 
system.  The  programs  written  in  high-level  languages  are 
limited  by  the  degree  of  interaction  provided  by  the 
corresponding  languages.  The  database  management  system  has 
no  means  of  incorporating  interrupt  driven  processing. 

Interrupt  driven  processing  requires  action  by  the  operatinq 
system  and  therefore  a close  relationship  between  the 
database  management  system  and  the  operating  system. 

The  database  management  system  approach  will 

adversely  affect  the  real-time  capability  of  the  program. 

Overhead  in  a database  management  system  is  extensive.  The 
desirable  trait  of  data  independence  requires  the  additional 
cost  of  address  translation.  Various  references  to  the  same 

translate  these  > 


references  into  the 


same  physical 


memory 


1 ocat i on 


Additional  overhead  in  execution  time  is  required  by  the 
necessity  to  translate  or  compile  input  requests  durinq 
execution. 

The  report  writer  is  facilitated  by  the  database 
management  system  approach.  The  database  design  allows  for 

the  user  to  request  information  in  a standard  format  and 
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have  it  displayed  for  him  on  the  screen.  Any  information 
stored  may  be  displayed  as  well  as  any  combination  of  data 
items  that  may  be  created  using  relational  calculus  or 
standard  boolean  operators. 

3.  Operating  System 

Under  the  operating  system  concepts  the  simulation 
program  becomes  one  of  many  in  a multiprogramming 
environment.  The  graphics  routines  are  organized  into 
programs  with  related  functions.  These  graphics  programs 
become  additional  programs  that  will  compete  with  all  other 
programs  for  system  resources. 

The  problem  of  sharing  files  is  not  significant  to  an 
operating  system  that  uses  segmentation.  Any  program 
division  that  is  important  enough  to  be  named  may  be  created 
as  a segment.  In  a system  supporting  this  segmentation#  any 
segment  may  be  addressed  by  potentially  any  processor.  By 
careful  designation  of  the  ability  to  read  and  write  to  a 
given  segment#  it  is  possible  to  allow  a segment  that  is 
responsible  for  a file  to  create  the  file  and  to  allow  a 
segment  that  must  use  that  data  for  display  or  other 
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purposes  to  access  the  data  and  use  it.  These  segments  that 
are  sharing  the  data  need  not  be  in  the  same  program.  The 
programs  need  only  be  active  at  the  time  of  sharing  of  the 
data.  One  potential  problem  may  arise  if  more  than  one 
segment  is  allowed  to  write  to  any  one  data  segment.  In 
this  case  the  last  segment  to  write  will  be  the  segment  that 

dictates  the  data  value  written.-  By  carefull  design  of  the 
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programs  involved*  this  problem  may  be  made  insignificant. 

The  ability  to  record  dynamic  events  such  as 

decisions  by  the  user  and  simulation  status  present  no 

significant  problem  for  the  operating  system.  At  the  time 

the  user  inputs  his  decision*  the  operating  system  needs  to 

write  the  input  data  into  the  aoprooriate  area  in  memory  to 

affect  the  simulation.  At  this  same  time  the  operating 

system  will  make  a copy  of  the  decision  information  along 

with  the  machine  state  and  any  pertinate  variable  values 

before  the  decision  is  made.  This  additional  information 
«• 

may  be  written  to  some  secondary  storage  medium  for  use  at  a 
later  time.  At  a later  time  when  it  is  desired  to  return  to 
a given  decision  point  and  change  or  modify  the  previous 
decision*  the  operating  system  has  all  the  information 
needed  to  restore  variable  values  and  restore  the  machine 
state.  Execution  may  then  resume  from  the  point  of  decision 
rather  than  requiring  the  entire  simulation  to  be  executed 
again. 

In  the  area  of  flexibility*  the  operating  system 
approach  presents  no  problem.  It  is  the  normal  function  of 


sene  operating  systems  to  allocate  storage  for  problem 
elements.  At  execution  time  the  operating  system  will 
allocate  storage  as  reguired  by  the  simulation  program. 

The  area  of  interactive  programming  is  affected  by 
the  interactive  capabilities  of  the  programming  language. 


These  built 

in  capabi 1 ities 

are  the 

base  level 

for 

the 

simulation. 

Further  interactive 

capabi 1 i t i es 

may 

be 

provided  by 

the  operating 

system. 

For  a system 

to 

be 

genuinely  interactiver  it  is  necessary  for  the  system  to  be 
interrupt  driven.  In  an  interrupt  driven  system^  the  user 
generates  an  interrupt  and  the  operating  system  then 
transfers  control  to  the  appropriate  interrupt  handler.  The 
instructions  in  this  interrupt  handler  dictate  the  response 
to  the  interrupt.  Operating  systems  allow  the  user  to  write 
his  own  interrupt  handlers  to  either  supplement  or  replace 
the  system  provided  handlers.  In  the  event  the  user  elects 
not  to  provide  his  own  handler^  the  operating  system 
provides  default  handlers.  By  anticipating  the  reguired 
types  of  interrupts  and  the  appropriate  responses»  the  user 
may  effectively  interrupt  the  execution^  create  a display  or 
input  data#  and  return  to  the  point  of  interruption  and 
continue  execution. 

The  operating  system  approach  may  enhance  the  real 
time  capability  of  the  simulation,  A multiprocessing 
environment  allows  the  operating  system  to  perform 
computation  on  one  process  while  simultaneously  performing 
i nput /output f paging  or  some  other  operation  on  another 
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process 


This  means  Che  oroQrams  of  the  simulation  may 


fully  utilize  the  processors  of  the  computer  system  and  the 
processors  need  not  be  idle  while  a single  program  switches 
from  one  processor  to  another  leaving  the  rest  of  the 
processors  idle  until  the  simulation  needs  its  services.  As 


a worst 

case# 

the 

operating  system 

will  add 

no  more 

execution 

time 

to 

the  program.  The 

operat i ng 

system  is 

needed  to  provide  user  interface  to  the  bare  machine  and 
hence  is  already  present  as  overhead  to  any  program  run  on 
Che  machine. 

The  post  analysis  report  writer  is  still  another 
program  to  exist  in  the  multiprogramming  environment.  The 
operating  system  keeps  the  segments  belonging  to  all 
simulation  programs  on  call  until  the  report  writer 
completes  its  usage  of  the  data.  Once  the  report  writer 
concludes  execution#  the  system  is  allowed  to  free  storage 
for  other  usage. 

4.  Distributed  System 

The  envisioned  solution  would  have  two  central  processors. 
The  simulation  functions  will  reside  on  the  main  orocessor 
due  to  it's  computation  bound  charac ter i st i cs # while  the 
graphics  and  inouiry  functions  will  reside  under  the  control 
of  another  possibly  smaller  orocessor. 

Since  the  main  CPU  is  charged  with  the  responsibility 
of  maintaining  the  master  data  base#  there  can  be  no  sharing 
of  data  items  between  processors.  The  graphics  processor 
must  receive  all  data  items  that  are  dynamically  changing. 


i 


60 


f 


It  must  also  Interpret  all  user  commands  and  generate  a CPU 
to  CPU  request  far  the  data  items  necessary  to  fulfill  the 
user's  request.  Any  attempt  to  store  these  ever  changing 
items  is  fruitless  and  will  result  in  either  duplicated 
files  or  excessive  data  transmission  between  the  two  CPUs. 
The  request  for  data  must  be  be  generated  on  an  interrupt 

basis  to  the  main  processor  so  .that  the  excessive  data 
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transmission  and  data  redundancy  situations  do  not  occur. 

Dynamic  event  recording  must  be  accomplished  on  both 
processors  to  enable  system  to  be  restarted  at  any  specified 
state.  The  graohics  processor  will  be  required  to  store 
user  commands  and  decisions#  machine  state  and  perhaps 
display  generation  data.  The  main  CPU  will  be  tasked  with 
saving  its  machine  state  and  all  variable  values  for  the 
simulation  restart. 

Flexibility  of  the  system  now  spreads  over  the  two 
processors.  Not  only  must  the  imolementer  be  concerned  with 
the  mechanism  for  level  of  olay#  level  of  display  and  size 
of  forces  represented  but  also  the  corresponding  volume  of 
data  transmission  between  the  two  processors.  This  is  an 
added  concern  in  the  distributed  approach. 

Since  interactive  play  is  desired#  the  graohics 
processor  must  interpret  the  user's  commands  in  an 
interactive  role  and  also  generate  an  appropriate  interrupt 
to  the  main  processor  for  each  type  of  request.  This  will 
require  a user  written  interrupt  handler  on  the  main 
processor  to  decipher  the  interrupt  and  process  it.  The 
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interrupt  handler  will  probably  not  be  on  the  operating 
system  level  and  thereby  will  cause  additional  delay  prior 
to  processing  it. 

The  idea  of  distributing  the  STAR  system  functions  to 
two  processors  was  conceived  to  solve  the  real-time 
requirement  problem.  Certainly  the  distributed  system  would 
run  closer  to  real-time  than  a Subroutine  call  system.  The 
required  CPU  to  CPU  communication  will  generate  some 
overhead  that  other  approaches  do  not.  The  user  must  see  the 
current  situation  status  displays  and  his  participation  must 
be  received  in  time  to  accurately  effect  the  outcome  of  the 
batt I e. 

The  problem  of  where  to  locate  the  report  writer  for 
post-execution  evaluation  arises.  It  should  be  capable  of 
providing  the  user  with  his  requirements  at  the  location 
generating  the  displays.  This  means  that  the  main  processor 
must  either  continue  to  function  only  to  pass  data  to  the 
graphics  processor  for  this  puroose  or  create  a file  that  is 
readable  by  the  graphics  processor  during  this  phase.  Once 
again  additional  overhead  is  required  to  accomplish  both.  In 
the  first  case  additional  execution  time  is  required  by  the 
main  to  retriever  process  and  transmit  data  to  the  graphics 
processor.  In  the  latter  case  additional  time  is  required 
to  create  the  readable  file  should  the  two  processors  expect 
different  file  characteristics.  The  overhead  of  generating 
the  file  remains  in  either  case  and  under  all  concepts 
discussedr  however  such  record  and  file  attributes  as 
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header*  trailer*  inter-record  gaps*  btoctclng  characteristics 


and  character  set  will  oresent  a problem  should  two 
different  hardware  vendors  be  chosen  for  the  two  processors. 

Since  unchanging  data  items*  'uch  as  terrain  and  road 
networks*  exist  during  the  execution  of  any  given 
simulation*  they  are  stored  on  the  graphics  side  of  the 

system  originally  and  do  not  require  the  passing  of  large 
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data  structures  as  that  of  terrain  representation.  This  is 
possible  due  to  the  use  of  oarameteri zed  terrain  generation 
capability  of  the  simulation  to  produce  terrain  elevations 
at  any  given  point  on  the  battle  field. 

5.  Embedded  Graphics 

In  this  approach  the  simulation  program  is  the  center 
of  control  over  all  desired  functions.  The  basic  functions 
of  graphical  display*  inquiry  and  update  are  fullfiled 
through  calls  to  appropriate  subroutines. 

SIMSCRIPT  uses  a basic  technique  of  executing  suoroutine 
calls  from  the  timing-routine.  This  technique  selects  the 
next  event  to  transpire  from  the  event  list.  These  events 
were  previously  scheduled  by  other  subroutines  in  the 
simulation  (internal)  or  received  as  input  (external). 

The  sharing  of  information  between  the  three  basic 
functions  (simulation*  graphics  and  inquiry)  presents  no 
problem  because  the  required  common  data  can  be  stored  in 
global  variables  or  passed  as  arguments  between  the  calling 
and  called  subprograms.  Data  integrity  also  presents  no 
particular  problem  since  only  one  subprogram  may  be  in 
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execution  at  any  one  time  unless  some  type  of  parallel 


processor  is  utilized.  The  same  argument  applies  when  one 
subprogram  updates  a variable  value  that  another  uses. 

The  recording  of  dynamic  events  can  be  easily 
accomplished  except  for  retention  of  the  machine  state. 
Since  machine  state  is  important  from  the  standpoint  of 

restarting  the  process  from  a specified  state#  an  assembler 
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level  subprogram  is  reauired  to  periodically  save  the 
necessary  information  on  some  secondary  storage  medium. 
Routines  will  also  have  to  be  developed  to  retain  the 
decisions  reached  and  periodic  simulation  state#  however 
these  can  be  written  in  the  basic  simulation  language  since 
all  reguired  information  is  defined  to  the  simulation 
program. 


Flexibility  of 

the 

system 

for  level  of 

play# 

1 eve  1 

of 

display  and 

si  ze 

of 

forces 

must  be 

des i gned 

into 

the 

subprograms 

but 

may 

be 

real i zed 

t h rough 

dynam i c 

initialization  of  key  execution  parameters.  The  structure 
to  allow  this  must  be  incorporated  into  the  subprograms  so 
that  the  maximum  allowable  force  sizes  can  be  allowed. 

Interactive  play  can  be  achieved  through  careful  design 
and  implementation.  A subprogram  to  periodically  test 
display  terminals  for  user  participation  is  reauired.  This 
subprogram  will  interpret  the  user's  desired  functions  and 
schedule  the  compatable  event  which  is  stored  in  the 
timing-routine  event  list  in  time  seouence.  These  events 
may  be  scheduled  NOW#  IN  10  MINUTES#  or  AT  1430  HOURS# 
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hoMever*  NOM  does  not  imply  instantaneous  execution  of  the 


function  since  other  previously  scheduled  events  for  the 
same  time  could  exist  with  a higher  statically  defined 
priori  tv. 

Maintaining  a real-time  environment  is  not  hindered  by 
this  approach  when  considering  effect  on  the  outcome  of  the 
simulationr  however  this  approach  w>i  1 1 extend  the  execution 
time  required  for  the  battle.  Should  the  user  desire  to 
update  the  simulation  data  during  the  execution#  the 
simulation  process  is  halted  by  the  resident  operating 
system  until  control  is  returned.  The  user  need  only 
schedule  a display  and  an  update  NOM  or  at  the  same  time 
with  the  display  event  having  the  next  highest  priority  to 
the  update  event.  During  execution  the  display  will  be 
produced#  showing  the  current  simulation  status  and  then  the 
update  event  will  execute. 

The  report-^wri  ter  enhancement  presents  some  difficulties 
particularly  during  post -s i mu  1 at i on  evaluation.  Since  the 
execution  of  the  simulation  has  been  terminated#  a separate 
application  program  is  required  to  process  the  saved  data 
for  the  user. 

Although  the  subroutine  call  approach  is  the  simplest  to 
implement#  it  does  have  the  drawbacks  indicated.  This 
approach  will  have  several  beneficial  side-effects.  The 
graphic  display  is  scheduled  along  with  all  other  events  and 
is  placed  in  the  event  list  in  the  appropriate  time 
sequence.  A display  event  can  be  generated  with  the  SCHEDULE 
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A GRAPHICS. DISPLAY  NOW,  SCHEDULE  A GRAPHICS. DISPLAY  IN  10 
MINUTES  (DAYS  or  UNITS)  or  SCHEDULE  A GRAPHICS. DISPLAY  AT 
1000  HOURS.  This  side-effect  qives  built-in  flexibility  to 
the  scheduling  of  a display.  The  "GRAPHICS. DISPLAY"  event 
includes  initiation  of  inquiries  and  updates  to  the  data 
base  as  well.  Figure  3.5  depicts  sample  SIMSCRIPT  code  for 


preamble 


EVENT  NOTICES  INCLUDE  STOP .SIMULATION 
EVERY  LOC. UPDATE  HAS  A VEHICLE 
EVERY  LOS. UPDATE  HAS  A WHEEL 

EVERY  DETECT  HAS  A WHOLE. TANK  AND  A 

DETECT. FOE. ENTIRE. TANK 

EVERY  TARGET. SELECT  HAS  A FIRING. TANK 

EVERY  FIRE  HAS  A SHOOTING . TANK  AND  A 

CORE. POINTER. OR. TGT. ID 

EVERY  IMPACT  HAS  A TANK. THAT. SHOT  AND  A 
BLOCK.POINTER.OR.TGT.ID  ■ , 

EVERY  GRAPHICS. DISPLAY  HAS  A COMMAND. ID  AND 
ADDRESS. OF. PARAMETER. LIST 

END 


MAIN 


CREATE  A 
LET 
LET 


SCHEDULE 
LET 

PARAMETER. LIST 

END 


PARAMETER. LIST 

ATTRIBUTE! (PARAMETER. LIST)  = value! 
ATTRIBUTE2(PARAMETER.LIST)  s value2 


A GRAPHICS. DISPLAY  NOW 

AOORESS.OF.PARAMETER.LIST(GRAPHICS.DISPLAY) 


EVENT  GRAPHICS. DISPLAY 


IF  command, ID(GRAPHICS. DISPLAY)  = 'I* 

PERFORM  INQUIRY  GIVEN 

ADDRESS. OF.PARAMETER. LIST (GRAPHICS.DISPLAY) 

IF  COMMAND. ID(GRAPHICS. DISPLAY)  s 'DT* 

PERFORM  TERRAIN. PLOT  GIVEN 

ADDRESS.OF.PARAMETER.LISTC GRAPHICS. DISPLAY) 


END 


FIGURE  3.5 


F.  PREFERRED  SOLUTION 


In  the  selection  of  the  preferred  alternative#  those 
items  designated  as  common  considerations  play  an 
insignificant  role.  The  use  of  color  to  enhance  the  clarity 
of  the  displays  is  not  envisioned  to  introduce  an  additional 
burden  on  any  solution.  The  method  used  to  rapidly  produce 

a contour  map  is  device  dependent  and  not  dependent  on  the 

✓ 

preferred  solution.  Hard  copy  devices  depend  on  machine 
interfaces  and  are  therefore  implementation  independent. 

It  is  possible  for  all  alternative  solutions  to 
accomplish  the  sharing  of  date  files.  Database  management 
systems  are  designed  with  this  goal.  Database  management 
systems  produce  a data  independence  that  allows  each  user  to 
view  the  data  in  his  own  way.  Operating  systems  that 
support  segmentation  are  also  capable  of  supporting  the 
sharing  of  data.  The  operating  system  however  shares  the 
data  in  a format  specific  manner.  The  distributed  aooroach 
allows  sharing  of  data  files  between  the  central  processors 
through  the  use  of  a distributed  operating  system  that 
allows  CPU  to  CPU  communication.  The  subroutine  call 
approach  uses  common  data  elements  through  parameter  passing 
technigues  and  global  variables. 

Dynamic  event  recording  is  the  first  area  in  which 
the  four  approaches  differ  significantly  in  their  ability  to 
perform.  All  approaches  are  capable  of  recording  decisions 
and  saving  the  values  of  variables  at  the  time  of  the 
decision.  It  is  not  a normal  database  management  function 
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to  record  and  later  restore  the  stat-e  of  the  machine 
registers.  This  interface  with  the  machine  must  be  made 
with  the  cooperation  of  the  operating  system.  The  operating 
system  aporoach#  on  the  other  hand#  has  the  interface  with 
the  machine  registers  as  part  of  its  normal  operations.  The 
distributed  approach  is  further  complicated  by  the  need  to 

save  the  state  of  multiple  CPU's  and  variable  values  in 
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multiple  machine  memories.  The  subroutine  call  approach 
suffers  from  the  inability  to  directly  access  machine 
registers  in  much  the  same  manner  as  the  database  management 
system. 

Flexibility  in  the  level  of  display  and  the  level  of 
play  must  be  discussed  in  two  aspects.  Level  of  display  is 
a function  of  the  level  of  play  in  the  fact  that  the  only 
possible  ‘items  to  be  displayed  are  those  items  that  are 


stored. 

The 

routines  written  to  cause 

the  display 

will 

be 

similar 

for 

all  approaches.  This 

1 eaves 

the 

area 

of 

flexibility 

as  a function  of  level  of 

play. 

The 

area 

of 

flexibility  of  play  hinges  on  the  ability  to  generate  and 
store  the  appropriate  data  structure.  This  poses  a problem 
to  the  database  management  system  approach  in  that  the 
system  must  dynamically  generate  the  data  structure  at 
execution  time.  The  generation  of  the  maximum  size  data 
structure  at  every  execution  of  the  simulation  would  be 
wasteful  of  storage.  The  operating  system  approach  is  not 
hindered  by  the  flexibility  constraint.  The  operating 
system  will  automatically  reserve  storage  for  the  data 
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structure  specified  by  the  simulation  program.  The 
distributed  approach  is  similar  to  the  operating  system 
approach  in  that  the  operating  system  of  the  distributed 
system  will  allocate  storage  as  required  by  the 
corresponding  programs.  The  subroutine  call  approach  is 
unaffected  by  the  flexibility  of  play.  By  changing  incut 
parameters#  the  user  may  dictate  the  size  and  structure  of 
the  units  participating  in  the  simulation. 


Interactive  programming  for  the  database  management 
alternative  is  broken  into  two  areas.  The  inquiry  mode  of 
the  database  system  is  limited  only  by  the  database 
designer.  Mhen  the  user  asks  and  what  he  is  allowed  to  ask 
are  design  considerations.  All  interactive  capabilities 
other  than  the  inquiries  are  limited  by  the  programming 
language  concerned.  The  subroutine  call  approach  is  also 


limited  by  programming  languages.  The  operating  system 
aoproach  is  capable  of  fully  interrupt  driven  processing. 
The  ability  to  interact  is  enhanced  by  the  users  ability  to 
write  interrupt  handlers  to  respond  to  user  generated 
interrupts.  The  distributed  system's  user  programs  are  also 
limited  by  the  chosen  programming  language. 

Real*time  processing  is  hindered  by  the  database 
management  alternative.  The  system  must  translate  all  data 
references  into  the  appropriate  addresses  in  order  to 
complete  the  data  references.  The  operating  system  approach 
does  not  affect  the  real-time  ability  of  the  simulation. 
The  distributed  system  will  slow  the  simulation  due  to  the 
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tim*  required  for  CPU  to  CPU  communicat i on 


The  greatest 


slow  down  will  be 'for  the  subroutine  call  alternative  since 
all  processing  must  stop  in  the  simulation  while  the 
subroutine  creates  the  display  data. 

From  the  above  discussion  the  operating  system 
approach  is  the  only  alternative  that  satisfies  all  the 

requirements  for  the  system.  -There  are  several  other 
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considerations  that  favor  the  operating  system  approach.  In 

the  operating  system  aporoach  the  key  is  the  sharing  of 

data.  The  key  data  to  be  shared  is  generated  by  the 

existing  simulation  program.  Further  program  development  to 

share  this  existing  data  may  be  done  independently  without 

adversely  affecting  the  existing  program. 

Another  consideration  is  the  availability  of  a system 

to  support  the  simulation.  Both  the  database  management 

system  and  the  operating  system  approaches  depend  upon  a 

complicated  programming  effort.  A tailored  database 
•* 

management  system  would  have  to  be  written  and  at  best  be  an 
experimental  system  with  unknown  efficiency.  On  the  other 
hand»  general  purpose  operating  systems  capable  of 
supporting  this  simulation  system  have  been  written  and 
tested.  These  proven  systems  are  available  today. 

It  is  anticipated  that  the  simulation  wi I be  run  with 
classified  input  data.  All  solutions  to  the  problem#  except 
the  operating  system  approach#  delegate  the  problem  of 
security  to  an  external  mechanism.  Some  operating  systems 
are  capable  of  providing  security  for  the  classified  data 
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without  depending  on  an  external  mechanism. 

The  last  consideration  is  the  complexity  of  the 
solution.  The  operating  system  approach  places  the  entire 
burden  on  the  operating  system  to  perform  tasks  beyond  the 
capability  of  the  programming  language.  The  database 
management  system  requires  a complicated  relationship 
between  the  database  system  and- the  operating  system  since 
the  database  management  system  is  unable  to  fulfill  all  the 
requirements.  The  operating  system  is  the  only  alternative 
to  perform  all  requirements  in  a stand-alone  basis. 
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synchronization  of  orocesses  and  segment  isolation 


1.  Segmented  Memory 

The  sharing  of  data  between  user  programs  is  required 
to  implement  the  STAR  model*  The  simulation  generates  a 
data  file  that  is  displayed  by  the  various  graphics 
routines.  This  data  file  is  accessed  by  the  routines  that 
display  dynamic  movements  animate  ^weapon  firing^  display 
impact  of  rounds^  and  display  unit  positions  as  well  as 
detected  enemy  positions.  This  data  must  not  only  be 
accessed  but  also  be  updated  by  the  routines  that  enable 
dynamic  route  and  position  selection  and  support  the  inquiry 
functions.  An  operating  system  capable  of  segmented  memory 
allows  this  sharing  to  take  place  [Daley  and  Dennis  19661. 

A segment  is  a collection  of  information  that  is 
important  enough  to  be  given  a name.  A segment  is  the  basic 
unit  of  sharing.  Associated  with  a segment  is  a collection 
of  attributes*  including  a unique  identifier  and  an  Access 
Control  List.  The  Access  Control  List  maintains  information 
specifying  the  processes  that  may  access  that  segment  and 
whether  the  authorized  access  includes  any  combination  of 
read*  write  or  execute  permission.  Each  segment  may 
consists  of  up  to  six  major  parts*  The  text  section 
contains  the  pure  unmodified  Parts  of  the  object  code  which 
would  contain  the  program  constants  as  specified  in  the 
SIMSCRIPT  preamble.  The  definition  section  contains 
nonexecutable  information  used  by  system  programmers  in 
debugging  and  by  the  operating  system  in  dynamic  linking. 
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The  linkage  section  contains  the  inpure#  modifiable  parts  of 
the  object  code  and  may  be  made  up  of  two  types  of  data. 
The  links  used  to  establish  addresses  at  run  time  are  the 
first  type  of  entry  and  since  the  memory  is  demand  pagedr 
these  addresses  may  change.  The  second  type  of  data  is  the 
data  items  from  the  program  that  will  be  modified  during 
execution.  All  variables  will  be's^ored  here.  The  static 
section  may  also  be  used  for  storage  on  a per  process  basis 
alternately  this  storage  may  be  included  in  the  linkage 
section.  A break  map  section  contains  information  used  by 
debuggers.  The  last  section^  the  symbol  section^  contains 
anything  generated  that  is  not  stored  elsewhere  [Honeywell 
19751  . 

All  segments  that  are  competing  for  system  resources 
are  listed  in  a system*wide  Active  Segment  Table.  This 
table  allows  the  operating  system  to  know  which  segments  are 
currently  active  and  where  they  are  located  in  memory. 
Table  length  is  finite  which  requires  the  operating  system 
to  limit  the  number  of  segments  capable  of  competing  for 
system  resources.  This  limiting  of  processes  reduces  the 
amount  of  time  lost  due  to  the  switching  of  processors  from 
one  process  to  another. 

2.  Process  States 

A process  is  a set  of  related  procedures  and  data 
undergoing  execution  and  manipulation.  Processes  will 
generally  contain  one  or  more  procedure  segments#  one  or 
more  data  segments#  a stack  segment  and  a linkage  segment 


for  each  procedure  segment  included  in  the  process* 
Processes  within  a'computer  fall  into  one  of  three  execution 
states.  A process  is  said  to  be  running  if  it  is  currently 
executing  on  a processor*  A process  is  ready  if  it  would  be 
running  should  a processor  be  available*  A process  is 
waiting  if  it  cannot  make  immediate  use  of  a orocessor  since 
it  is  waiting  for  some  external  (to  the  process)  event*  The 
operating  system  keeps  track  of  these  processes  in  the 
system*wide  Active  Process  Table.  These  three  types  of 
processes  in  the  Active  Process  Table  require  synchronized 
use  of  shared  segments* 

3*  Synchronization  of  Processes 

In  order  to  synchronize  processes  some  method  of 
communication  between  the  processes  must  exist*  This 


interprocess  communication  is  monitored  by  a mechanism  known 
as  the  traffic  controller  which  functions  as  a general 
purpose  supervisor  for  control  of  parallel  operations  (Daley 
and  Dennis  19681*  Two  of  the  more  interesting  mechanisms 
provided  by  the  traffic  controller  are  the  block  and  wakeup 
functions*  The  block  function  forces  a orocess  to  wait  for 
an  occurrance  of  an  event  generated  by  some  other  process 
while  the  wakeup  function  allows  the  process  to  be  notified 


processes  through  the  use  of  condition  handlers.  Condition 
handling  refers  to  an  activity  resulting  from  a hardware  or 
software  condition  named  by  the  user's  program.  The  user 
may  implicitly  or  explicitly  identify  the  code  to  be 
executed  in  response  to  the  condition.  To  initiate  user 
interaction  with  the  simulationf  the  programmer  specifies 
the  pressing  of  the  ATTN  key  on  t'h^  terminal  keyboard  as  a 
hardware  condition.  In  response  to  this  condition/ 
execution  control  is  transferred  to  a condition  handler 
which  contains  code  to  request  the  type  of  action  required 
by  the  user.  The  user  performs  his  desired  interaction  and 
the  simulation  resumes  execution.  Condition  handling  need 
not  be  a rigid  response  to  the  specified  condition.  The 
programmer  has  the  option  to  specify  condition  handlers  on  a 
segment  by  segment  basis  since  condition  handlers  are  pushed 
onto  a stack  as  they  are  defined  and  popped  from  the  stack 
when  the  procedure  segment  for  which  they  are  defined  is 
exited.  In  this  manner/  the  programmer  may  specify  a global 
condition  handler  as  the  general  response  to  a given 
condition  and  redefine  the  response  to  the  condition  on  a 
procedure  by  procedure  basis  should  the  response  change  for 
each  particular  environment.  Shpuld  the  response  to  the 
condition  be  the  activation  of  another  procedure/  the 
condition  handler  then  becomes  another  of  the  deliberately 
cooperating  procedures. 

Deliberately  cooperating  programs  or  procedures  may 
interact  through  the  use  of  interrupts  which  are  synchronous 
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events  {nternel  to  the  machine*  When  one  procedure  desires 
to  call  another  procedure*  the  calHnq  procedure  generates 
an  interrupt*  The  key  to  flexibility  in  interrupt  handling 
is  to  convert  this  interrupt  to  a wakeup*  The  interrupt  is 
sent  to  the  interprocess  communication  controller  which  in 
turn  sends  a wakeuo  to  the  called  procedure.  This  called 

procedure  is  then'act i vated  and  execution  may  resume*  There 

✓ 

is  no  problem  with  simultaneous  use  of  a procedure  by 
multiple  calling  procedures  since  all  references  to  the 
called  procedure  are  made  via  the  calling  procedure's 
linkage  segment.  Once  the  called  procedure  has  completed 
execution*  the  called  procedure  places  itself  in  a blocked 
status  to  await  further  use  (Graham  and  Denning  19721. 

Coordinated  sharing  of  writable  data  segments  may  be 
handled  through  a lock  mechanism  provided  by  the  operating 
system.  This  lock  mechanism  is  applied  to  a data  segment 
whenever  that  segment  is  being  utilized  by  a process  capable 
of  modifying  its  contents.  Further  attempts  to  reference  a 
locked  segment  will  be  denied  until  the  segment  is  unlocked. 
The  lock  mechanism  blocks  the  process  that  is  attempting  to 
use  data  segment  and  maintains  the  identification  of  the 
requesting  process  in  a list  structure.  Once  the  segment 
has  been  updated*  the  locking  mechanism  sends  a wakeup  to 
the  next  process  selected  to  use  the  data*  unlocking  the 
data  segment  for  that  process*  This  procedure  is  repeated 
until  all  requests  are  fulfilled  and  the  data  segment  is 
unlocked  to  await  future  use* 
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4.  Isolation  Techniques 


Interprocess  isolation  is 

accompl i shed 

through 

the 

Access 

Control  List 

di scussed 

in  section  A 

-1  of 

this 

Chaptar 

. Intraorocess 

isolation 

is  implemented 

1 rough 

the 

use  of  concentric  protection  rings  where  a ring  bractcet  is 
associated  with  each  segment.  The  ring  bracket  is  an 
ordered  triple  <R1/R2»R3>  which  specifies  the  access  bracket 
<RWR2>  and  the  call  bracket  <R2»R3>.  These  two  subsets  of 
the  ring  bracket  dictate  the  readr  write#  execute  and  call 
access  for  that  segment.  A procedure  may  execute  in  any 
ring  from  R1  to  R2  inclusive  and  may  be  called  by  any 
procedure  in  rings  (R2  + 1)  to  R3  inclusive#  orovideO  the 
calling  procedure  has  sufficient  security  clearance.  A data 
segment  commonly  has  R2  equal  to  R3  since  calling  a data 
segment  has  no  meaning.  A procedure  segment  may  write  to  a 
data  segment  in  rings  0 to  R1  inclusive  and  read  from  a data 
segment  residing  in  the  region  0 to  R2  inclusive.  Again# 
read  and  write  access  are  denied  to  any  segment  in  any  ring 
that  does  not  have  sufficient  access  granted  in  the  Access 
Control  List. 

A segment  may  also  have  a security  level  associated 
with  it.  This  security  level  is  composed  of  two  parts# 
security  classification  and  security  category  (Schiller 
19751.  The  security  classification  is  a type  of 
compartmental i zat i on  similar  to  the  Department  of  Defense 
security  classifications  secret#  confidential#  etc.  This 
security  classification  is  a totally  ordered  set  where 


secret  is  strictly  greater  than  confidential  and  so  forth 
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The  second  part  of  the  security  level  is  the  security 
category  whicn  is  a modifier  to  the  security  classification 
and  analogis  to  the  Department  of  Defense  categories  of 
cryptOf  NATO,  etc.  In  addition  to  access  granted  by  the 
Access  Control  List»  procedures  must  also  have  an 
appropriate  security  level  in  orders  to  gain  access. 

B.  analysis  of  enhancements. 

Certain  design  characteristics  must  be  followed  in  the 
design  of  all  software  for  the  proposed  system.  All 
software  developed  should  be  easily  portabler  avoiding 
locally  produced  library  functions  since  they  may  not  exist 
at  another  installation.  All  modules  should  be  h^uman 
engineered  to  permit  easy  use.  Operator  inputs  should  be 
minimal  and  concise  with  default  values  provided  for  all 
modest  parameters  and  variables.  These  defaults  lessen  the 
burden  on  the  user  and  facilitate  the  requirement  for 
minimal  input.  Addi t ional 1 yr  defaults  reduce  the  number  of 
user  errors.  Maintenance  responsibility  for  the  software 
must  be  charged  to  a specified  individual  or  group  of 
knowledgeable  individuals.  All  graphics  routines  developed 
should  comply  with  the  new  graphics  standards  under 
development  by  the  American  National  Standards  Institute 
[Newman  and  van  Dam  1*)78]  . 

In  addition  to  the  existing  simulation  program^  several 
new  modules  and  separate  programs  must  be  written  to  achieve 
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the  type  of  interactive  simulation  described  in  Chapter  II. 
These  additional  modules  and  programs  include  all  graphical 
displays^  inquiry^  synchronization  and  report  generator 
f unct i ons. 

The  choice  of  utilizing  the  operating  system  approach  to 
implement  the  simulation  system  has  facilitated  the 
programming  effort  required.  The'  jsrea  of  flexibility  of 
play  no  longer  concerns  the  programmer.  Storage  for 
variables  is  automatically  allocated  as  a normal  function  of 
the  operating  system.  The  programmer  does  not  need  to 
concern  himself  with  an  elaborate  data  structure  that  is 
capable  of  growth  since  this  burden  is  assumed  by  the 
operating  system.  Flexibility  of  display  becomes  a problem 
of  searching  for  all  the  elements  of  the  unit  being 
displayed  and  then  using  some  appropriate  weighting  factor 
to  properly  position  the  unit  symbol. 

Programs  may  be  developed  independently  of  the 
simulation  by  using  simulated  data  files  and  therefore  not 
hinder  the  use  of  the  simulation  or  require  duplicate  copies 
of  the  simulation  program  for  developmental  purposes.  Mhen 
the  additional  programs  are  tested  and  pronounced  ready  for 
user  the  only  action  required  is  to  inform  the  operating 
system  to  allow  access  to  the  shared  data  files. 
Synchronization  of  use  of  these  shared  files  is  required  but 
mechanisms  discussed  in  section  A-3  of  this  chapter  allow 
this  synchronization  to  occur. 

1.  Interactive  Programming 


The  area  of  interactive  programming  may  be  broken 
into  two  sect  ions* ' The  user  may  interact  with  the  simulation 


program  as  well  as  the  individual  simulation  programs 
interacting  with  each  other.  The  case  of  the  user 
interacting  with  the  simulation  may  be  satisfied  by  the  use 
of  condition  handlers  while  individual  programs  cooperating 
with  one  another  may  be  accompi  i'sh^ed  through  the  use  of 
interrupt  handlers. 

An  example  of  condition  handling  may  be  the 
implementation  of  dynamic  route  selection.  Mhen  the  light 
pen  is  activated*  a hardware  condition  occurs  and  execution 
control  is  transferred  to  the  condition  handler.  The 
condition  handler  sends  a wakeup  to  an  updating  procedure. 
This  updating  procedure  accesses  the  data  and  places  a lock 
on  the  data  segment.  This  lock  prohibits  the  use  of  the 
data  while  it  is  being  updated.  Mhen  updating  is  completed* 
the  lock  is  removed*  the  updat?  procedure  places  itself  in  a 
blocked  status  to  await  its  next  wakeup  message*  the 
condition  handler  is  exited  and  execution  resumes. 

Use  of  coordination  by  interrupt  handling  may  be  seen 
in  the  dynamic  updating  of  positions.  Mhen  the  movement 
module  changes  the  location  of  the  unit*  an  interrupt  is 
generated  as  the  movement  module  is  exited*.  This  interrupt 
is  converted  into  a wakeup  that  is  sent  to  the  display 
routine.  The  display  routine  creates  the  new  display  and 


then  places  itself  in  blocked  status  to  await  the  next 
position  change.  This  conversion  of  interrupts  to  wakeups 
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not  only  facititates  display  but  also  allows  the  proceoure 
to  me  active  only-  as  required.  Extraneous  nonexecuting 
simulation  routines  need  not  be  in  primary  storage  until 
required  for  use  and  display  routines  need  not  continuously 
draw  the  same  picture  in  order  to  prevent  missing  an  event. 
Displays  may  now  be  made  only  as  change  occurs. 

2.  Real-time  ' ^ 

Real-time  must  be  approached  from  both  the  computer 
science  and  modeling  definitions.  The  computer  science  real 
time  is  accomolished  by  the  synchronization  mechanisms 
discussed  in  section  A»3.  The  various  programs  and 
procedures  are  forced  to  run  in-step  since  they  are  called 
by  wakeups  from  the  main  simulation  on  an  as  required  basis. 
T-his  system  will  have  least  overall  detriment  to  the 
simulation  in  the  modeling  real-time  sense.  Memory 
management  may  prove  to  slow  the  simulation  from  paging 
activities  but  proper  selection  of  the  program's  working  set 
size  will  reduce  these  oaging  delays  to  a minimum  (Denning 
19601.  A clever  operating  system  will  have  facitities  for 
maintaining  the  current  working  set  size  as  a program 
executes.  Associative  and  cache  memories  will  also  speed  up 
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be  overcome  since  separate  programs  will  be 

allowed  to  execute  simultaneously  in  a multiprogramming  and 


multiprocessing  environment.  An  example  of  synchronization 
of  segment  usage  i's  the  calculating  line  of  sight  while  the 
display  of  current  positions  is  being  oroduced  by  another 


processor. 

5.  Monitor  Program 

The  monitor  program  provides  a master  control 
facility  for  the  modeler.  This  monitor  program  provides  the 
main  condition  handler  for  the  simulation.  From  the  master 
console,  any  capability  of  the  simulation  system  may  be 
called  at  any  time.  Any  privileged  instructions  available 
to  the  modeler  but  not  the  war  gamer  will  be  executable  from 
thi s terminal . 

The  monitor  program  will  be  written  as  a separate 
program  executing  on  a dedicated  display  device.  All 
modules  of  the  monitor  program  will  be  of  sufficient 
priority  to  preemot  any  of  the  executing  routines  of  the 


This  state  of  execution  is  composed  of  two  distinct  parts 


with  distinct  characteristics*  The  state  of  the  simulation 
is  the  set  of  values  of  all  simulation  variables.  Mhenever 
a decision  is  input/  the  operating  system  needs  to  copy  the 
data  segments  containing  the  appropriate  variable  values 
onto  a secondary  storage  device.  These  values  must  be 

copied  prior  to  any* changes  due  to  the  input  decision.  The 
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state  of  the  machine  is  characterized  by  the  values  in  the 
machine's  Internal  registers.  At  the  decision  point/  the 
operating  system  saves  the  register  values  in  secondary 
storage.  The  operating  system  must  then  label  these  values 
and  inform  the  user  of  the  assigned  label  and  resume 
execution.  At  some  future  time  when  the  user  desires  to 
return  to  this  ooint/  he  need  only  supply  the  label  value  of 
the  decision  point  and  the  operating  system  will  then 
restore  the  simulation  and  execution  states/  returning 
control  to  the  user  for  his  new  decision. 

5.  Report  Writer 

The  purpose  of  the  report  writer  is  to  produce 
statistical  reports  based  on  stored  historical  data  and 
current  battle  status.  It  should  have  the  capability  to 
produce  graph  summaries  of  the  user's  desired  format.  For 
instance/  bar  graphs  may  be  desired  over  simple  plots  for 
certain  items.  For  esse  of  implementation/  this  should  be 
defined  as  a user  requirement  however  the  report  writer  can 
be  developed  with  sufficient  flexibility  to  allow 
interactive  user  format  selection  at  the  expense  of  larger 
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program*.  If  sufficient  storage  space  (memory  or  secondary) 


exists  and  system  execution  is  not  sufficently  degradedr 
then  this  f 1 ex i b i 1 i t y shou 1 d be  pursued  for  the  benefit  of 
the  ultimate  user. 

The  report  writer  is  a orocedure  included  in  the 
administrative  routines  program.  Proper  selection  of  ring 
brackets  and  delegation  of  access 'p^rmi ssion  will  allow  the 
report  writer  to  reference  data  and  perform  its  required 
function.  The  report  writer  may  be  invoked  from  either  the 
administrative  program  or  the  monitor  program.  The  invoking 
program  sends  a wakeup  to  the  report  writer  to  initiate  the 
procedure.  Upon  completion^  the  report  writer  places  itself 
in  a blocked  status  to  await  further  use. 

6.  Inqui ry  Mode 

I i 

The  function  of  the  inquiry  mode  is  to  allow  ' 

commanders  and  their  staff  sections  to  Question  the 

simulation.  Legitimate  inquiries  are  those  that  each  agency  i 

would  normally  initiate  during  an  actual  battle.  For  I 

I 

instance  the  S“1  would  not  be  allowed  to  query  directly  the 

status  of  some  area  outside  his  cognizance  but  rather  | 

i 

require  him  to  communicate  via  the  appropriate  agency  which 
has  cognizance  over  the  area  in  question.  Chapter  ^ 

section  0 previously  identified  normal  areas  of  cognizance 
for  the  staff  sections.  i 

Answers  to  any  agency's  request  must  reflect  the  | 

accuracy  and  timeliness  experienced  in  a true  battle.  This  ^ 

requirement  should  be  handled  in  the  simulation  of  inter- 
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organi z»t { onal  communication  oaths.  Any  accurate  and 
instantaneous  reply'  could  be  misleading  to  to  the  commander. 
Human  factors  must  be  considered  and  accounted  for  in  the 
inquiry  mode's  operation  to  reflect  realism. 

7.  Map  and  Overlay  Generation 

Initial  terrain  generation  experiments  were  conducted 
on  a POP  11/50  using  a TEKTR0NICS^<i014-l  display  device  as 
the  display  medium.  The  4014  has  several  display  modes 
including  point  and  vector.  A resulting  tutorial  was 
developed  for  use  and  is  included  as  APPENDIX  A. 

Current  methods  used  for  generating  contour  maps  from 
stored  matrices  of  data  could  not  be  used  to  display  the 
terrain  for  this  simulation  [Oayhoff  19631.  One  of  the 
advantages  of  parametric  terrain  is  that  terrain  may  be 
calculated  rather  than  stored  allowing  large  areas  to  t)e 
modeled.  Using  calculated  terrainr  the  only  altitude  known 
is  that  of  the, current  location.  The  decision  was  made  to 
scan  the  area  from  South  to  North  and  from  West  to  East  to 
determine  the  location  of  contour  lines.  The  resulting 
problem  was  that  with  a constant  sampling  step  sizer  it 
could  not  be  guaranteed  that  the  step  taken  would  in  fact 
fall  on  a contour  line.  Next  a point  was  accepted  as  being 
on  a given  contour  line  if  it  were  within  a specified 
tolerance  from  the  contour  line.  This  tolerance  was 
measured  in  the  vertical  direction.  The  first  attempt  at 
displaying  parametric  terrain  utilized  the  point  mode  of  the 
4014,  The  deficiency  noted  in  this  approach  was  the 
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inability  to  establish  contour  lines  since  the  display  image  | 

consisted  of  a series  of  dots.  To  accomplish  the  illusion  of  ] 

I 

lines  a sufficiently  small  delta  x and  delta  y had  to  be  i | 

used  thus  extending  execution  time  for  any  given  piece  of 

terrain.  If  the  display  wav^  to  be  magnified  to  any  degree 

the  line  illusion  became  visible  dots  or  points  once  again.  i 


This  effect  demonstrated  the  he^d  to  draw  contour  lines 
using  the  vector  mode  of  the  4014. 


In  order  to  utilize  the  vector  mode.  a drawing 
algorithm  was  developed.  The  algorithm  used  to  determine 
the  direction  of  draw  was  quite  simple.  Once  a decision  to 
draw  was  made,  all  points  adjacent  to  the  current  point  in  a 
North  or  East  direction  were  calculated  and  the  line  was 
drawn  to  the  point  closest  to  the  contour  elevation.  This 
approach  produced  contour  bands  rather  than  contour  lines. 
These  bands  were  acceptable  on  steep  slopes  but  in  the 
flatter  areas  j:hev  were  quite  wide.  An  attempt  to  reduce 
the  number  of  line  segments  to  be  drawn  was  made  by  drawing 
to  a given  point  only  if  the  ooint  immediately  North  of  it 
was  farther  from  the  contour  line  than  the  current  point. 
This  produced  contour  lines  that  were  shaded  on  the  North 
side.  The  solution  to  this  problem  resulted  in  an 
additional  condition  that  a point  would  not  be  considered 
for  plotting  unless  it  were  closer  to  the  contour  line  than 
both  the  adjacent  points  in  the  North  and  South  directions. 
The  resulting  map  was  adequate  but  still  retained  shading 
along  a hill's  major  access  in  the  area  of  the  contour  line 
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plus  and  minus  the  tolerance*  The  shading  was  negligible 
near  the  oeak  of  the  hill/  but  quite  distracting  near  the 
base.  The  shape  given  by  the  distribution  is  increasingly 
flatter  as  one  proceeds  outward  from  the  center  of  the  hill. 
The  solution  to  this  problem  was  in  the  calculation  of  a 
dynamic  tolerance.  This  tolerance  was  calculated  by 
determining  the  distance  frbm^  hill  center  that  the 
distribution  reached  three  standard  deviations  or  fell  below 
some  specified  minimum  altitude/  whichever  comes  first. 
This  method  produces  an  acceotable  mao.  The  resulting 
algorithm  follows: 

1.  Locate  point  closest  to  contour  line. 

2.  Sample  adjacent  points  to  North  and/or  East. 

3.  Draw  line  to  adjacent  point  closest  to  contour 

line. 

Locate  next  point  closest  to  next  contour  line. 

The  major  drawback  to  this  approach  lies  in 
consumption  of  time.  This  method  is  of  complexity  of  order 
N squared  meaning  that  doubling  the  size  of  the  mao  to  be 
displayed  roughly  quadruples  the  execution  time.  This 
routine  is  by  no  means  real-time  in  nature.  Experiments 
were  conducted  to  speed  up  the  drawing  of  this  contour  map. 
The  map  may  be  drawn  in  real-time  if  the  calculations  are 
not  required  every  time  the  terrain  is  displayed.  The 
solution  requires  that  the  commands  to  move  and  draw  that 
are  generated  by  the  CPU  and  sent  to  the  display  device  must 
be  intercepted  and  written  to  a data  file.  Upon  a request 
to  draw  a given  area/  only  the  actual  move  and  draw  commands 


need  be  executed.  These  commands  may  be  created  and  stored 


as  tKe  terrain  is  designed  and  referenced  later  during  the 
simulation  as  required. 

The  ability  to  draw  different  sections  of  the 
battlefield  is  easily  attained.  By  using  a device  such  as 
the  TCKTKONIX  4014  a virtual  window  may  be  defined  to  the 
display.  This  virtual  window  is  mapoed  onto  the  physical 
display  window  and  only  the  poi nfs ^wi t h i n the  virtual  window 
are  displayed.  This  virtual  window  may  be  dynamically 
created  from  input  parameters  from  the  console.  The  contour 
lines  may  be  stored  in  separate  files  per  individual  line 
elevation  thus  allowing  combinations  to  be  plotted  and 
giving  flexibility  of  selection  of  line  interval. 

Overlays  will  be  plotted  on  the  basic  contour  map. 
These  overlays  may  be  selected  individually  or  in  any 
combination  of  the  available  overlays.  The  use  of  color 
displays  will  make  the  overlays  stand  out  from  the  map  and 
avoid  confusion  when  multiple  overlays  are  requested.  In 
order  to  avoid  destruction  of  the  contour  map  by  overwriting 
from  the  overlays^  the  display  terminal  must  have  a 
selective  erase  capability.  This  will  allow  the  removal  of 
a specific  overlay  without  disturbing  any  others  that  may  be 
displayed  at  the  time  of  removal. 

8.  Security  of  Classified  Data 

Physical  security  of  the  classified  data  during  input 
or  output  remains  the  problem  of  the  user.  The  terminals 
used  must  be  in  a secure  environment  to  avoid  compromise 
before  data  is  entered  into  the  computer  and  after  the 
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classified  output  is  generated.  Remote  use  of  the 
simulation  will  be'possible  if  scrambling  devices  are  placed 
on  the  communication  lines.  Computational  security  is 
provided  by  the  operating  system  since  properly  specifying 
the  security  level  of  the  simulation  will  cause  the  internal 
protection  mechanisms  to  safeguard  the  data  from  tampering 

within  the  computer.  Thus  the  simulation  running  classified 
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data  may  be  described  with  a security  level  of 
<c I earance^ ST AR>  and  thereby  refuse  usage  of  the  data  to 
anyone  regardless  of  classification  without  STAR  access. 

9.  Library  Routines/Tutorials  Needed 

In  any  interactive  system  certain  library  routines 
and  tutorials  make  the  system  more  convenient  to  use.  These 
routines  lie  resident  within  the  system  and  are  capable  of 
being  called  by  the  user.  Several  readily  identifiable 
examples  are  discussed  in  the  following  sections, 
a.  Terrain  Generation  Package 

The  purpose  of  the  terrain  generation  package  is 
to  allow  the  user  to  define  any  given  terrain  area  in  terms 
of  the  reauired  parameters  prior  to  the  execution  of  the 
battle  simulation.  The  terrain  generation  package  uses  the 
identical  data  items  reguired  by  the  elevation  routine  of 
the  simulation.  Once  the  user  has  defined  the  terrain  to 
his  satisfaction  he  can  elect  to  creat  a file  containing  the 
display  device  commands  generated  during  the  display  phase. 

The  terrain  generation  package  includes  two  major 
itemsr  a highly  interactive  program  and  a tutorial 
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describing  the  program's  use.  The  interactive  program 
allows  the  user  to  define  and  display  the  terrain  of  the 
battle  area.  The  definition  phase  includes  capabilities  to 
buildf  modify#  add-to  or  delete-from  a data  file  containing 
the  parameters.  Appendex  A defines  these  allowable 
funct ions. 

The  terrain  display  phase  allows  the  user  to  draw 
contour  lines  of  his  chosen  level  from  the  data.  The  user 
specifies  bounds  for  the  display  in  terms  of  maximum  and 
minimum  grid  coordinates#  the  contour  level  and  the  step- 
size  desired.  The  user  specified  bounds  give  the  illusion 
of  zooming-in  or  away  from  the  terrain.  Bounds  smaller  than 
the  defined  battle  area  will  cause  a smaller  area  to  be 
displayed  in  the  static  display  window  creating  a blown-up 
or  zoom-in  effect.  Conversely#  should  bounds  larger  than 
the  battle  area  be  prescribed#  a reduction  or  zoom-out 
illusion  is  created.  All  displays  are  generated  without  the 
need  to  store  in  memory  an  elevation  for  each  <x,y> 
location. 

The  terrain  generation  program  contains  the 
following  functions.  The  user  is  allowed  to  build  the 
parametric  data  file  under  a filename  of  his  choosing.  He 
is  allowed  to  add#  delete  and  modify  the  file  to  reflect  the 
current  state  of  terrain  generation.  There  should  be  a 
narrative  portion  which  describes  the  function  of  the 
program  and  demonstrates  effects  of  different  input 
parameters.  The  user  should  also  be  allowed  to  familiarize 
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defined  terrain  is  also  provided, 
b.  Position  Selection 

The  purpose  of  the  position  selection  package  it 
to  allow  the  user  of  STAR  to  selecjt  defensive  positions  and 
routes-of -march  for  his  forces.  This  oackage^  like  the 
terrain  generation  package,  is  primarily  a pre-execution  or 
set-up  operation  designed  to  facilitate  planning  of  a 
battle.  Execution  during  the  battle  will  give  the  user 
insight  as  to  possible  new  positions  or  tactics  as  the 
battle  progresses.  Since  interaction  between  user  and 
simulation  is  provided  for,  the  user  may  desire  to  utilize 
information  gleened  from  the  position  selection  package  to 
perform  uodates  during  the  simulation. 

The,  position  selection  program  should  use  the 
contour  mao  generated  by  the  terrain  generation  package  and 
determine  1 ine-of-sight  (LOS)  fans  for  any  selected  position 
within  the  battle  area.  There  are  two  approaches  to  the 
representation  of  LOS  fans,  each  with  it's  own  advantages 
and  disadvantages.  The  first  approach  is  to  shade-in  the 
vis able  area  in  the  fan.  This  method  gives  the  user  a 
distinct  impression  of  how  much  area  the  fan  covers. 
However,  specific  terrain  characteristics  within  the  fan  may 
be  hidden  from  the  user's  view.  To  counter  this 
degredation,  the  package  should  allow  the  user  to  display 
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the  fan  fn  an  inverted  mode.  This  inverted  mode  should 


shade  the  areas  outside  the  LOS  fan  thus  allowing  the  user 
to  see  only  geographic  features  defined  within  the  fan. 
These  two  approaches  when  combined  should  allow  the  user  all 
LOS  related  information  concerning  that  position.  Figures 
4,1  and  4,2  depict  the  results  of  the  two  methods. 


I 

\ 

i 

i 


I 

i 

i 


Figure 


c.  Military  Symbol  Library 


i 


The  purpose  of  the  military  symbol  library  is  to 
allow  the  user  either  through  his  interaction  or  program 
action  to  select  a series  of  predefined  display  device 
commands  to  draw  a standard  military  symbol.  This  functions 
somewhat  like  a table  lookup  procedure  where  the  resulting 
table  entries  are  a aeries  of  /entries  that  define  a 
particular  symbol.  The  map  overlay  display  programs  must  be 
able  to  access  this  library  and  retrieve  these  instructions 
for  dynamic  display  during  the  battle. 

Military  leaders  are  innovative  when  a standard 
symbol  has  not  been  defined  for  some  unique  application  and 
consequently  establish  some  symbol  to  represent  their  new 
weapon  or  unit.  The  program  should  allow  the  user  to  define 
any  additional  symbols  needed.  A standard  checker«board 
pattern^  such  as  figure  4.3»  should  be  provided  on  the 
display  screen. 


1 
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figure  A. 3 

The  user  can  select  any  square  and  the  program 
that  area.  By  continued  selection^  the  user 
symbol  of  his  choosing.  After  the  user  has 
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symbol  to  his  satisfaction#  the  proqram  shoul d display  the 
symbol  for  final  approval  of  size  and  features.  The  symbol 
may  now  be  stored  in  the  library  for  future  reference. 


C.  USE  OF  THE  SYSTEM 

The  simulation  system  will  be  useful  in  all  phases  of 
modelinp.  A typical  senario  may  Yollow  this  outline.  The 
life  of  a simulation  beoins  with  the  writing  and  debugging 
of  the  code.  The  simulation  implementer  may  sit  in  his 
office  and  enter  the  code  through  a console  as  opposed  to 
punching  data  cards  and  feeding  them  into  a card  reader.  As 
the  implementer  finishes  entering  the  code#  he  may  now 
compile  the  program  and  correct  any  syntax  errors  from  the 
console.  Execution  may  reveal  problems  with  his  code  that 
may  also  be  corrected  from  his  console. 

The  user  of  the  simulation  takes  over  after  the 
implementer  his  finished  and  the  model  is  ready  for  use. 
The  user  must  first  set  up  the  model  for  use.  This  set  up 
is  facilitated  by  the  tutorials  provided  by  the  system.  The 
terrain  generation  package  explains  the  method  of  generating 
terrain.  The  user  uses  this  terrain  package  to  generate  and 
store  the  parameter  values  necessary  to  create  ana  display 
the  terrain.  Using  the  1 ine-of-sight  capability  of  the 
system#  the  user  then  selects  the  initial  positions  for  the 
elements  on  the  battlefield  using  the  LOS  fans  provided  by 
the  system. 

The  modeler  is  now  ready  to  use  the  simulation.  As  the 
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A.  GENERAL 


V.  ANALYSIS  OF  CURRENT  STAR 


The  analysis  conducted  on  the  current  version  of  STAR 
was  Performed  in  the  general  areas  of  program  structure^ 
control  structure#  storage  optimization  and  subroutine 
analysis.  Certain  guidelines  were  used  in  the  analysis  of 
the  current  version  of  STAR.  The  programming  language  used 
is  SIMSCRIPT.  The  methodology  used  in  the  simulation  will 
be  left  to  the  programmer  and  comments  will  be  limited  to 
programming  technigues. 

8.  STRUCTURE 

The  SIMSCRIPT  programming  language  has  the  capability  to 
be  both  readable  and  structured.  Readability  and  structure 
allow  the  program  to  be  maintained  by  persons  other  than  the 
original  writers.  This  capability  of  the  language  is  not 
being  fully  exploited.  Good  readability  facilitates  ease  of 
maintenance  and  debugging.  To  attain  the  desired  level  of 
readability  several  principles  must  be  followed. 


Indentation  should  be  present  to  offset  the  control  j 

structure  from  the  code  that  is  contained  within  that  i 

\ 

structure.  For  example#  should  the  "if"  in  an  "if  else"  j 


! i structure  be  indented  five  spaces#  the  "else"  should  also  be 

^ indented  the  same  number  of  spaces.  Only  one  source 


stAtenvnt  should  bo  allowed  to  a line.  AM  local  variables 


should  be  defined  rather  than  allowing  the  default  values  of 


SIHSCRIPT  to  take  precedence.  Variable  names  should  be 


since  SIMSCRIPT  al lows 


occur  in  the  STAR  orogram  either  through  ease  of  use  or  bad 


programming  practices.  These  shorter  names  contribute  to 


ambiguity  and  confusion.  One  example  of  lack  of  structure 


is  seen  in  the  following  code  extracted  from  the  current 


model 


until  jji  = M do 

let  target (nameC tank ) #2)  - he.drag(tank) 
let  he.dragC tank)  s 0 let  mv.state(tank) 
let  defnum(tank)  = I 
let  jji  = jji  ♦ 1 loop 


This  code  will  be  more  readable  if  it  were  structured 


let  target (name(tank) f 2) 
let  he.drag( tank ) - 0 
let  mv.seate(tank)  s 1 
let  defnum(tank)  = 1 
let  jji  5 jji  t 1 


This  type  of  structure  has  two  major  benefits 


easily  recognise  the  scope  of  the  UNTIL  statement  and  the 


assignment  statements  are  readily  found  since  they  are  one 


per  line  and  begin  with  the  reserved  word  LET 


Another  example  of  how  structure  may  lead  to 


understanding  is  found  in  the  following  segment  of  code  from 


the  routine  CH6.SEC .SEARCH 


-dl*» 


if  css(a)  s 1 
- go  to  dll 
else 

go  to  dl2 

•dll* 

let  Dri,dip(a)  * pi .c/2 
let  css(a)  s 0 
go  to  set 

•dl2" 

let  zyx  * uni  form. f (0.  « 1 1 ) 
if  zyx  ge  .5 

go  to  dl3 

else 

go  to  dl4 

"dl3" 

let  pri.dir(a)  - pi .c/4 
let  css(a)  = 1 
go  to  set 

•dia* 

let  pri.dir(a)  = 3*pi .c/4 
let  css(a)  • 1 
go  to  set 

■set" 


Upon  examining  this  unstructured  version  of  STAP  source 
code»  it  is  evident  that  it  may  be  replaced  by  the  following 
sequence: 

•dl*' 

if  css(a)  ~ 1 

let  pri.dir(a)  = oi  .c/2 
let  css(a)  s 0 
go  to  set 

else  , 

let  css(a)  e 1 
if  uni  form. f (0. » 1 1 ) ge  .5 
let  pri.dir(a)  s pi. c/4 
go  to  set 

el  se 

let  pri.dir(a)  - 3*pi.c/4 

•set" 


This  code  sequence  is  easily  understood  ana  has  ~ two 
additional  benefits.  First#  this  structured  code  will 


execute  faster  due  to  fewer  transfers  of  control.  Second# 


storage  requlrsfflents  are  reduced  since  this  version  has 
fewer  lines  of  source  code  » thirteen  instead  of  twenty* 
four*  thereby  reducing  object  code  storage  requirements  and 
does  not  require  the  variable  "tyx". 


C.  CONTROL  STRUCTURES 

The  STAR  model  needs  extensive  optimization  in  the  area 
i of  control  structures.  The  following  example  is  from  the 
1 routine  COMMO.PASS.TGT, 


if  pet. vis  gt  cri t ical . val ue 
let  lose  • 1 
Jump  ahead 

el  se 

let  lose  = 0 

here 

if  lose  eq  0 

let  aim  s 0 
return 

el  se 


This  code  sequence  is  equivalent  to  the  following: 


if  pet. vis  le  critical. value 
let  aim  s 0 
return 

el  se 


The  sequence  may  be  reduced  even  further  if  the  variable 
"aim”  is  initialized  to  zero  since  this  is  the  majority  of 
usage  ("aim”  is  set  to  zero  four  times  as  opposed  to  one 
only  once).  This  saving  in  storage  of  object  code*  ease  of 
understanding  and  execution  speed-up  is  attained  by  testing 
"less  than  or  equal  to”  as  opposed  to  "greater  than".  This 
particular  type  of  control  structure  is  used  in  other  places 
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in  the  program  as  well.  f 


I Another  common  'eont ro1  structure  abuse  is  observed  in 

I the  routine  REStt.  This  routine  has  seven  "do  loops”#  all 

[ indexed  from  1 to  2.  These  loops  may  be  combined  into  one 

i ■ 

‘ control  structure  which  will  result  in  a reduction  in 

I 

I execution  time  (counter  maintenance)  and  a saving  in  object 

code  storage.  The  combination  of  "do  loops"  is  possible  in 
the  majority  of  the  STAR  routines. 

Another  optimization  technioue  applies  to  the  routine 
PRIORITY. AND. ROUND. SELECT  with  the  foilwing  code  seauence: 


let  i = i - I 

go  to  iO#  i3f  i6#  i9#  il2  per  i 

"iO" 

let  i = 0 I 

go  to  bands 

"i3"  I 

let  i = 3 ' 

go  to  bands 

"16"  j 

let  i = 6 

. go  to  bands  I 

"19" 

let  i = 9 
go  to  bands 

"i  12" 

let  i = 12 
go  to  bands 

"bands"  i 


A little  "cleverness"  reduces  this  sequence  to 
i = (i  - 2)  * 3 

In  fact#  in  this  routine  alone#  fifty*four  lines  of  source 
code  may  be  reduced  to  four  lines  without  loss  of  meaning. 
Benefits  of  the  reduction  include  ease  of  understanding# 
more  efficient  execution  and  less  storage  requirements. 


0.  STORAGE  OPTIMIZATION 


Storage  optimization  can  occur  in  several  ways  in  the 
STAR  model*  Aopendices  C and  0 present  the  storage 
regutrements  of  the  current  unstructured  model.  The 
"complexity"  item  under  each  routine  analysis  in  Appendix  8 
indicates  storage  dependencies. 

Another  area  that  deserves  .close  monitoring  is  the 

✓ 

assignment  of  subscripts  in  arrays.  An  example  of  this 
detrimental  effect  is  seen  in  the  array  called  TARGET.,  The 
actual  variable  is  TARGET(321  ^2) . SIMSCRIPT  creates  a data 
structure  with  321  pointers  to  vectors  of  length  2.  By 
reversing  the  subscripts  giving  TARGET(2> 321 ) the  SIMSCRIPT 
compiler  stores  this  with  2 pointers  of  length  321.  This 
reversal  of  subscripts  saves  319  words  of  storage  or  1278 
bytes  of  memory.  If  at  all  possibler  subscripts  should  be 
arranged  with  the  smallest  first  and  in  increasing  order. 

Appendir  D gives  a summary  of  all  static  storage  arrays 
and  the  storage  required  if  an  optimal  assignment  of 
subscripts  is  used.  By  this  use  of  optimal  subscripts 
approximately  12K  bytes  of  storage  may  be  saved. 


E.  SIMSCRIPT  ROUTINE  ANALYSIS 

The  SIMSCRIPT  routine  analysis  was  performed  after  a 
structured  version  of  STAR  was  produced.  All  names  are 
alphabetical  within  their  category.  For  each  subroutine  the 
following  items  were  identified: 

1.  Parameters  passed  to  the  subroutine. 
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2.  Local  variables  defined  to  that  subroutine. 

3.  Global  variables  accessed. 

4.  Variables  read  into  the  subroutine. 

5.  Variables  written  to  print. 

6.  Data  structures  created. 

7.  Data  structures  filed  into  a predefined  set. 

8.  Data  structures  removed  from  a set. 

9.  Data  structures  destroyed. 

10.  Vectors  or  matrix  for  which  storage  is 
reserved. 

11.  Vector  or  matrix  for  which  storage  is  released. 

12.  Other  subroutines  called. 

13.  Subroutines  that  call  the  subroutine. 

14.  Events  scheduled. 

15.  Subroutine  that  schedules  the  event. 

16.  Complexity  of  subroutine  in  regard  to 
ej<ecution  time  and  storage  requirements. 

17.  Recommended  improvements  (excluding  general 
improvements  identified  earlier). 

18.  Any  remarks  concerning  the  subroutine  and 
values  returned  to  the  calling  program. 
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VI. 

I 


CONCLUSIONS  AND  RECOMMENDATIONS 


The  STAR  war  gaming  model  is  written  using  sound 
modeling  techniques.  The  i mo  I ement at i on  does  have  a serious 
drawback  in  maintainability.  Nithout  structurer  this 
program  is  difficulty  at  best,  to  understand  and  will  be 
extremely  difficult  for  anyone  other  than  the  actual  code 
writers  to  maintain.  The  current  version  of  STAR  is  at  this 
time  undergoing  extensive  modification  to  give  the  program 
structure  and  to  attempt  to  gain  efficiency  to  both  storage 
and  execution. 

This  thesis  is  a preliminary  design  and  therefore  only  a 
preferred  solution  was  given.  As  the  preferred  solution  is 
developed  at  a later  timey  more  detail  may  be  given  as  to 
the  final  implementation  of  the  STAR  model.  The 
i mpl ementat i on'of  STAR  using  the  operating  system  approach 
may  be  attempted  here  at  the  Naval  Postgraduate  School . The 
features  described  that  are  necessary  to  implement  the 
proposed  enhancements  are  found  in  the  MULTICS  operating 
system  from  Honeywell  Information  Systemsy  Inc.  which  is 
available  on  the  ARPANET.  This  availability  gives  the 
school  the  opportunity  for  further  study. 

One  of  the  most  beneficial  short  term  improvements  that 
can  be  made  is  to  obtain  an  interactive  SIMSCRIPT  compiler. 
The  interactive  compiler  may  be  obtained  free  of  charge  from 
Consolidated  Analysis  Centersy  Inc.  under  the  university 


/ 
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grant  program 


1 


Further  experimentation  with  graphical  displays  may  be 
made  at  the  Nava)  Postgraduate  School  utilizing  the  research 
computer  in  the  school  graphics  laboratory.  This  computer 
may  be  used  as  a remote  terminal  to  the  w.R.  Church  Computer 
Center  and  graphics  displays  oroduced  on  the  terminals  in 
the  laboratory. 

✓ 

The  STAR  wargame  provides  excellent  opportunity  for 
further  computer  science  thesis  work.  Additional  thesis 
material  may  include  optimization  of  terrain  display  using 
the  parametric  method  of  terrain  representation.  Thesis 
work  in  the  area  of  operating  systems  may  include  actual 
implementation  of  the  STAR  model  on  the  ARPANET.  Work  in 
the  database  area  will  be  required  to  develoo  the  induiry 
capability  and  the  reoort  generator. 


APPENOEX  A 


AN  INTRODUCTION  TO  INTERACTIVE  TERRAIN  REPRESENTATION 
UTILIZING  PARAMETRIC  TERRAIN  GENERATION 

I.  INTRODUCTION  ^ 

This  tutorial  has  been  develooed  to  allow  interactive 
use  of  parametric  terrain  generation.  Currently  mechanisms 
exist  for  building  and  modifying  the  input  file  required  for 
the  generation  of  terrain  features  and  displaying  contour 
lines  of  the  user's  desired  level.  Due  to  modular  design^ 
further  terrain  enhancements  such  as  three-dimensional  views 
from  any  point  may  be  developed  and  incorporated  into  the 
existing  program. 

Parametric  terrain  generation  uses  as  incut  parameters 
the  X and  y locations  of  the  center  of  the  hill  (xc  and  yc ) » 
the  elevation  at  that  <xc#yc>  location  (peak)^  tne 
eccentricity  of  the  hill  Cecc)#  the  height  of  the 
parameterized  hill  (ht)^  the  angle  of  rotation  of  the  hill 
from  an  East-West  axis  (angle)  and  the  spread  of  the  hill 
(sprd).  For  each  set  of  hill  values  there  is  a base 
a 1 1 i tude/e I evat i on  Cbasealt)  associated.  This  base  altitude 
is  the  elevation  of  the  lowest  point  in  the  terrain  area 
that  is  being  modeled.  The  eccentricity  of  the  hill  (ecc) 
is  the  ratio  of  major  axis  to  minor  axis  (major-axis/minor- 
axis)  for  the  hill  under  consideration.  The  spread  of  the 
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hHI  {s  considered  to  be  the  distance  along  the  major-axis 


for  the  elevation -to  drop  fifty  (50)  meters.  Figures  A-l.l 
through  A»1.5  graphically  explain  these  parameters. 


FIGURE  A-1,1 


FIGURE  A-1.2 


axis 

ecc  ■ major/minor 


FIGURE  A-1.3 
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II.  HAROMARE  REQUIREMENTS 


A.  INTRODUCTION 

The  display  hardware  utilized  in  the  development  is 
centered  around  the  TEKTRONICS  40I4>1  storage  tube  graphics 
display  system.  It  has  a 19  inch  storage  tube  as  a display 
medium.  Associated  with  the  4(M4  is  a standard  ASCII 
Keyboard. 

A VERSATEC  MATRIX  printer  is  accessable  through  the 
POP  11-50  and  allows  hard  copy  generation  from  the  4014 
display.  A hard  copy  of  the  4014  display  screen  can  be 
obtained  by  depressing  the  copy  key  located  on  the  upper 
right  portion  of  the  keyboard. 

The  POP  11-50  with  the  UNIX  timesharing  system  is 

a 

utilized  and  assumes  the  4014  is  a conventional  alphanumeric 
CRT  allowing  the  user  to  "login"  normally.  Section  IV 
discusses  these  "^login”  procedures. 


B,  SYSTEM  OPERATION 

The  4014  is  powered  on  by  turning  the  off-on  switch^ 
located  under  the  keyboard  about  one  foot  from  the  floors  to 
the  on  position.  After  turning  the  device  onr  wait 
approximately  30  seconds  before  proceeding  to  allow  the 
device  to  warm  up.  The  screen  will  appear  a bright  green  and 
now  must  be  erased  by  depressing  the  page  reset  key  on  the 
upper  left  portion  of  the  keyboard.  Should  a residual  image 
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•PP««r  on  th«  seroen*  wait  approximately  seconds  and 
depress  tHe  page  reoet  key  once  again.  Insure  that  the  mode 
toggle#  located  above  the  page  reset  key#  is  in  the  online 
position  rather  than  local.  Depress  the  carriage  return  and 
wait  for  the  UNIX  timesharing  system  to  request  "login". 
Follow  normal  POP  11-50  login  procedures. 
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Ill,  DESCRIPTION  OF  PROGRAM  FUNCTIONS 


A.  MAIN 

The  mein  program  requests  the  name  of  the  data  file 
that'  the  user  desires  to  operate  on  during  this  terminal 
session.  The  user  enters  the  filename#  upon  request  in 
either  upper  or  lower  case  letters#  that  he  either  desires 
to  use  or  create.  The  filename  is  limited  to  eight 
characters  but  the  user  may  specify  any  length  filename  and 
the  program  will  only  use  the  first  eight#  terminating  all 
others.  For  this  reason  the  first  eight  characters  of  any 
filename  should  be  unique.  If  the  filename  is  not  an 
existing  file#  the  program  will  create  it  for  the  user.  If 
the  file  does  exist#  the  program  will  open  that  file  for 
read  and  write  access  to  the  user.  A command  list  is 
displayed  next  to  allow  the  user  to  select  that  function  he 
desires  and  enter  the  appropriate  command  code  when  prompted 
by  the  program.  The  main  program  is  developed  around  a CASE 
statement  to  allow  the  user  to  perform  his  desired 
functions.  Control  remains  in  this  CASE  statement  until  the 
user  elects  a code  of  "7"  to  terminate  the  session.  When 
the  user  selects  code  7 the  program  displays  the  current 
state  of  the  data  file  that  the  user  selected  during  the 
beginning  of  the  session  on  the  4014  and  updates  the  file 
for  future  use.  Should  the  user  not  desire  to  retain  the 
current  copy  of  the  file#  he  may  exit  the  program  by 
depressing  the  rub«out  key  located  on  the  lower  right 


portion  of  the  keyboard*  (This  method  of  program  termination 
is  not  recommended -as  a short-cut  however.) 

B.  AOO 

The  add  function  allows  the  user  to  add  another  set 
of  hill  values  to  the  data  file  specified  in  the  beginning 
of  this  terminal  session*  Addition  of  hill  values  is 
accomplished  by  adding  them  to  the  end  of  the  data  and 
incrementing  the  number  of  hills  on  the  file.  The  program 
will  prompt  the  user  for  each  data  item  required  for  the 
hill  and  give  the  user  the  option  of  adding  multiple  hills 
or  only  a single  hill*  All  hill  values  are  floating  point 
numbers,  however,  the  user  need  not  specify  a decimal  ooint 
if  that  value  is  a whole  number  since  the  program  is  capable 
of  interpretation  in  this  case* 


C*  BUILD 

The  build  function  gives  the  user  the  capability  to 
initially  build  the  file  specified  during  the  beginning  of 
the  terminal  session*  Care  must  be  taken  to  prevent 
building  a file  that  already  exist  since  the  building 
process  will  over-write  all  data  previously  resident  on  that 
file.  Building  is  accomplished  by  requesting  from  the  user 
the  number  of  hills  he  desires  to  load  to  the  file.  Next 
the  program  will  prompt  the  user  as  in  the  add  function  for 
all  neccessary  hill  values*  The  program  will  allow  the  user 
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to  only  buHd  one  file  per  terminal  .session.  Howeverr 
should  the  us’er  desire  to  build  multiple  fiies  he  may  do  so 
by  building  the  first  one  and  then  enter  a command  code  of 
"7"  to  exit  the  program.  Subseouent  file  building  is 
accomplished  by  repeating  this  same  procedure. 

0.  CHANGE 

The  change  process  is  actually  a modify  process  since 
it  allows  the  user  to  change  or  modify  any  single  hill  data 
item  or  all  data  items  for  a hill.  The  program  prompts  the 
user  for  the  hill  number  he  desires  to  changer  allows  the 
user  to  select  the  data  item  to  be  changed  and  then  reguests 
the  new  value  that  is  to  be  substituted.  The  change  function 
will  allow  the  user  to  change  one  hill  or  many  hills  by 
asking  the  user  if  he  has  any  more  changes. 


E.  DELETE 

The  delete  function  allows  the  user  to  delete  a 
complete  set  of  hill  values  for  the  hill  number  specified 
from  the  data  file.  Deletion  is  accomplished  by  requesting 
the  number  of  the  hill  that  the  user  desires  to  deleter 
locating  that  set  of  hill  values  and  shifting  all  higher 
hill  number  values  downr  overwritting  the  deleted  hill  and 
decrementing  the  number  of  hills.  It  is  recommended  that  if 
multiple  hills  are  to  be  deletedr  the  highest  hill  number  be 
used  first  to  prevent  the  user  from  losing  track  of  the 
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current  hill  numbers  since  the  deletion  process  also 
logically  decrement's  the  hill  number.  Multiple  deletes  may 
be  accomplished  since  the  program  will  ask  the  user  i f he 
desires  to  delete  another  hill. 


F.  PLOT 

The  plot  function  uses  the  'parametric  input  data# 
which  is  located  on  the  file  specified  by  the  user#  and 
generates  contour  lines  of  the  user  specified  contour 
interval.  The  program  prompts  the  user  for  the  minimum  and 
maximum  x locations#  the  minimum  and  maximum  y locations# 
the  contour  interval  desired  and  the  minimum  elevation  in 
the  area  to  be  displayed. 


G.  MISCELLANEOUS 

The  first  miscellaneous  routine  to  be  discussed  is 
the  "writefile"  routine.  This  routine  restores/writes  the 
hill  data  from  memory  to  a secondary  storage  (disk)  file  for 
subseduent  use  by  the  user.  The  number  of  hills  is  written 
first  followed  by  all  x locations  (xc).  The  file  structure 
is  completed  by  writing  the  entire  y locations  (yc)#  hill 
spread  values  in  the  x direction  (sx)#  spread  values  in  the 
y direction  (yc)#  the  rotation  values  respectively  and 
closing  the  file. 

The  "readfile"  routine  functions  like  the  "writefile" 
function  but  loads  the  hill  values  from  the  secondary 
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storage  (disk)  file  into  memory.  The  filename  used  is  that 
specified  by  the-  user  at  the  beginning  of  the  terminal 


r- 


session.  i 

The  "printfile"  routine  disolays  to  the  a01«  the  hill 
data  located  in  memory  starting  with  hill  number  one  and 
continuing  to  the  number  of  hills  that  are  being  used  in 
this  session. 

/ 

The  "invalidcmd"  routine  produces  appropriate  error 
messages  to  be  displayed  on  the  4014  for  the  user.  The  user 
must  heed  the  error  message  and  take  appropriate  action 
accordingly. 

The  "cmdlist"  routine  displays  all  function  codes  to 
the  user.  It  is  from  this  list  that  the  user  must  select 
the  command  code  corresoondi ng  to  the  function  desired  and 

I 

i 

enter  it  when  promoted  oy  the  program.  All  commands  must  be 
followed  by  a carriage  return. 

IV.  SYSTEM  USE 

To  initiate  the  program  execution  after  powering  on  the 
4014  the  following  procedures  must  be  followed.  The  first 
step  is  to  login  to  the  UNIX  system  with  a name  of  "parry" 
and  a password  of  "parry".  (Note  all  entries  are  lower  case 
letters.)  The  second  step  is  to  enter  "terrain"  followed  by 
a carriage  return  and  the  program  will  begin  execution 
prompting  the  user  as  needed  to  step  the  user  through  the 


required  procedures. 


APPENDIX  8 


AMMO, CHECK 

NUMBER  BYTES  OBJECT  CODE  ; 496 

PARAMETERS  : 
a 

LOCAL  VARIABLES  *. 
a 

rnd 

GLOBAL  VARIABLES  : 
ap«tow 
aw2 .or ,adm 
C.2 

wpn.type 

called  by  : 
priori Cy .and. round .sel act 
t72. tactics  we. miss 

complexity  : Constant  storage  requirement  and  execution 
time. 

e 

remarks  : This  routine  returns  the  value  of  answer  to  the 
calling  rout i ne . 


rnd 


answer 


awl .or.fflsi 3 
c . 1 

he. drag 


[ 

ARTY. IMPACT 

1 NUMBER  BYTES  OBJECT  CODE  : 1312 

I parameters  : 

I id.btry 

id.fdc  i 

1 id.fo 

id.mission  I 

i 

1 LOCAL  VARIABLES  : ! 

t ans 

est i mate.of . t i me  j 

i 

id.btry  | 

Id.fdc 

id.fo  \ 

id.misslon 

■ i ! 

; »« 

; m 

rg 

time 

t i me. 1 

( time. 2 

t ime.3 

‘ time.<l 

t i me.5 

1 time.b 

t i me.  7 

9 wi t h i n • to1 erance 

X X 

; yv 

T 

' GLOBAL  VARIABLES  : 

caliber 

debug 

del.l 

del  .2 

^ error. code 

gsrs.code 

) gt. final .rg 

1 ast .fo. rg 

^ mi ss.tol erance 

msn.name  J 

1 msn.time 

my.  radio  1 

no.mi ssi ons . f i red 

now .firing  ! 

num.ad j . rounds 

num.dpi cm. 1 ef t | 

1 rate. of. fire 

rd.l. error  1 

rd. 2. error 

st.fi  ring  ’ | 

thet3 

t ime.v  j 

volley 

vol 1 eys . to. f i re  j 

wh i ch . VO  1 lev 

x.curl 

X .cur4 

X. future. loc 

! y.curl 

y .cur4 

y.future.loc 

WRITES  : 

i 

id.fo 

id.btry  \ 

id.fdc 

msn.name  1 

vol 1eys.to.fi  re 

num.ad j . rounds  | 

wi thin.tol erance 

I 

time.v  ! 

I 

1 

r-  — - .. 

) 

f 
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ARTY. IMPACT  (cont) 


CALLS  : 

arctan. f 

assessment 

error 

posi t { on .update 
pr i nt 1 

SCHEDULES  : 

busy.radio.net 
guns.fi  ring 

SCHEDULED  BY  : 

guns . firing 


arty.t ime 

di  St 

new .location 
print 
t racer 


end.of .ffl i ss i on 
open.radio.net 


complexity  : Execution  is  linear  on  vo 11 eys . to . f i re  but 
constant  storage. 

ARTY. TIME 


NUMBER  OF  BYTES  OBJECT  CODE  : 416 


parameters  : 


LOCAL  VARIABLES  : 


GLOBAL  VARIABLES  : 

f a . t i me.del tas 


CALLS  : 


norma  1 . f 
un i form . f 


del .time 


rn, St  ream 


t racer 


CALLED  BY  : 

arty . i moac t 

checki ng.guns.avai lability 

commo. at  tempt  end.of .mi ss i on 

fdc. processing  update. c 1 uster 

complexity  : Constant  execution  time  and  storage. 

remarks  : Returns  the  value  of  del. time  to  the  calling 
rout i ne. 


ASSESSMENT 


■Sr.' 


.NUMBER  BYTES  OBJECT  CODE  : 4528 


PARAMETERS  : 

id.btpy 

id.fo 

LOCAL  VARIABLES  : 

count 

di f f erenc© 
i d.bt  py 
Id.fo 
j 
1 

Pk 

sig.y 
X .eppop 
xdt  f 

y .change 
y .nopmal .cppop 
ynew 

GLOBAL  VARIABLES  : 

a1 i ve.dead 
amt  .of  .hi ts 
debug 

di spi acement 
f .d 
fki  1 I 

gt .f i nai . pg 
kki  1 1 

lethal .padius.a 
m.d  " 
mk  i 1 1 

num.dpi cm. 1 eft 
nuffl.he. left 
p. punch 
pn .St  peam 
t i me.  V 
X .cuppent 
X .mpi 

y . f utupe. 1 oc 
2 .cuPPent 


i d. f dc 
i d.mi ssi on 


debug. count 
i 

i d. f dc 
id.mi ssion 
'k 
m 

sig.x 
X .change 
X .nopma I .error 
xnew 
y .eppop 
ydi  f 


ammun i t i on . t ype 

call bep 

de  f num 

d.padi us 

f i ped.at 

foe 

hit. state 
1 apgest .num.wpns 
ray  1 eve  1 .of .damage 

mf k i 1 1 
fflsn .name 
num .guns 
num.h i t 
pd.of f set 
theta 
wpn.type 
X . f utuPe. 1 oc 
y .cuppent 
y .mpi 


I 

! 
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ASSESSMENT  (cont) 


MRITES  : 


ammuni t i on. type 

cal i ber 

def num 

di f f erence 

f*d 

f i red. at 

fki  1 1 

guntube 

hi t .state 

i 

kki  n 

m.d 

mf  k i 1 1 

mki  1 1 

name 

ncase 

num.h  i t 

spd 

t ime.v 

current 

V. current 

z .current 

RESERVES 

• 

• 

rd.of f set 

RELEASES 

• 

• 

rd.of f set 

CALLS  : 

abs.  f 

at  r i t 

di  St 

1 oc 

new. coordinate. system 

normal . f 

parameters 
pr  i nt  1 

print 

CALLED  BY 

• 

• 

arty . i mpact 

complexity  : Execution  dependent  on  num.guns  and  tank  in 
red.aiive.  Storage  dependent  on  1argest.num.wpns. 

IMPROVEMENTS  : Reverse  subscripts  on  rd. offset. 
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ii. 


J 


F 

ATRIT 

; 

NUMBER 

BYTES  OBJECT  CODE  : 2256 

parameters  : 

‘ 

' 

tfki 1 1 

amk i 1 1 

' 

kayk i 1 1 

sh . t 

. 

tgt  .t 

whocal 1 ad 

LOCAL  VARIABLES  : 

•fki 1 1 

amk i 1 1 

f now 

kayk i n 

mnow 

pk 

sK  .t 

tgt  .t 

1 

whocol 1 ed 

! 

1 

GLOBAL  variables  : 

a1 { vo.dead 

damaga.num 

f.d 

d 

mf ki  1 1 

mina.dat 

ink  i 1 1 

oh 

WRITES  : 

«fk<'l  1 

amk i 1 1 

f .d 

fki  1 1 

kayki 1 1 

m.d 

mf kil  t 

mk  i 1 1 

P** 

CALLS  : 

uni  form* f 

CALLED  BY  i 

assassmant 

gaom 

mrl .impact 

pop. a. mi ne 

rad.arty.f i raa 

SCHEDULES  : 

final .daath 

complexity  : Constant 

avecution  time  and  storage 

• 

raqui ramants* 

; - 
1 , 

i 
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' ; 

i 

ATTRITION. CHECK 


r 


NUMBER  BYTES  OBJECT  CODE  : 496 


GLOBAL  VARIABLES  : 

b.pct  .att 
n.bl ue.al 1 ve 
PC. count 
p.nuffl.al i ve 

CALLS  : 

i nt . f 

SCHEDULES  : 

attri t ion. check 

SCHEDULED  BY  : 

attri tion.check 


del ta.t 
n. red.a) i ve 
r.pct .att 


stop.si mul at i on 


mai  n 


complexity  ; Constant  execution  time  and  storage 
reoui rements. 


BASIC. LOAD 


NUMBER  BYTES  OBJECT  CODE  : 2088 

PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 


GLOBAL  VARIABLES  : 


ap.tou 

awl  .or .msl 3 

c.l 

c.2 

capds 

caseap 

casehe 

cheat 

he.drag 

hto 

ml 

m2 

m3 

name 

op.rng 

wpn.type 

CALLED  BY  : 

b1 .create 

red. create 

complexity  : Constant 

storage  and  execution  ti 

r 
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BL. CREATE 


NUMBER  BYTES  OBJECT  CODE  ; 282« 


LOCAL  VARIABLES 


GLOBAL  variables  : 

•O.tow 
b.num.al i v* 
cocdr 
d«f num 
guntube 
mv. state 
OD.rng 
pi .hat 
pi 1 1 dr 
pri ,di r 
p.con 
sec 

veh.tvpe 
X .current 
z. current 


bn 

CO 

color 

di r.of .mvmt 

Jl  i St 

name 
pi  .c 
pit 

pol nter 
rc  .count 
rrrpoi nt 
target 
wpn. type 
y .cur rent 
zh 


READS 


bn 

cocdr 
name 
pi tl dr 
sec 

Mpn.type 
y .current 


CREATES 


tank  in  comp. unit 
tank  in  tanks 


RESERVES 


CALLS 


CALLED  BY 


complexity  : Storage  and  execution  depend  on  num. alive 


BMP. TACTICS 


i 

i' 


• NUMBER  BYTES  OBJECT  CODE  : 26A 


PARAMETERS  : 

a b 

LOCAL  VARIABLES  : 

a answer 

b 

GLOBAL  VARIABLES  : 

CO  comp. unit 

foe  ^ tank 


CALLED  BY  : 

target .select 

complexity  : Constant  storage  but  execution  time  is  linearly 
dependent  on  the  number  of  tanks  in  comp. unit 

remarks  : This  routine  returns  the  value  of  answer  to  the 
calling  rout i ne. 


BUG. CHECK 

NUMBER  BYTES  OBJECT  CODE  : 102a 

PARAMETERS  : 

a 


LOCAL  VARIABLES  : 
a 

be 

GLOBAL  variables  : 

CO 

def num 
mv .state 
range 
t .spd 

CALLS  : 

dr.mount 

CALLED  BY  : 

i mpact 

SCHEDULES  : 

df .change 

complexity  : Constant  storage  but  execution  in  linearly 
dependent  on  tanks  in  comp. unit 
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b 


b 


comp. uni t 
m2 

pi t .uni t 
tank 

wpn .type 


BUSY.RAOIO.NET 

NUMBER  BYTES  OBJECT  CODE  : 240 


parameters  ! 

Id. radio 

LOCAL  VARIABLES  : 

id. radio 

GLOBAL  variables  : 

States 

CALLS  : 

t racer 

SCHEDULED  BY  : 

arty.imoact  quna. firing 

complexity  : Constant  execution  time  and 

regui rements. 
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I Mill  Jt  .“-wj— 


storage 


yigBEL' 


LOCAL  VARIABLES  : 

a 

area 

b 

dd 

det.time 

mt 

pet .vl s 
r 

t .c • factor 

GLOBAL  VARIABLES  : 

b.araa 

ebar 

d<  r .of  .mvint 
pi .hat 
r .area 
sod 

y .current 


CALLS 


abs.  f 
tog.e.f 


angl  e 

at 

bt 

denonn 
I ambda 
p.sub . k 
per .fu) 1 .expo 
rr 

tgt .el ement 


b1  ue 
color 
pi  .c 
pr i ,di r 
red 

X .current 
z1 


arctan . f 
s i n . f 


CALLED  BY  : 

step. time 

complexity  : Constant  execution  time  and  storage 

requi rement  s. 

IMPROVEMENTS  t Alt  local  variables  need  to  be  defined. 

REMARKS  : Returns  the  value  of  det.time  to  the  calling 
rout i ne. 


CAROIO 

•NUMBER  BYTES  OBJECT  CODE  : 1280 


PARAMETERS  : 

a b 

pet.vis  r 

X 


CHARGE 


NUMBER  BYTES  OBJECT  CODE 


parameters 


LOCAL  VARIABLES 
•vgxc 
•vgxb 
•vgyc 
•vgy6 


GLOBAL  variables  : 
bn 

tank 

* .currant 
y .currant 


CALLS 


SCHEDULES 


SCHEDULED  BY 


complexity  : Execution  time  is  linear  on  number  tanks 
red. alive.  Storage  requirements  are  constant. 


CHECKING. GUNS. AVAILABILITY 


NUMBER  BYTES  OBJECT  CODE  : I82a 


PARAMETERS  : 


i d.bt  ry 
id.fo 

i d. fdc 
i d.mi ss i on 

LOCAL  VARIABLES  : 

id.btry 
id.fo 
t i me 

i d. fdc 
i d.mi ssi on 

GLOBAL  VARIABLES  : 
dt  ry 

f i re.di r .center 
msn .name 
num.adj .rounds 
queue. si ze 
state 
st.f i ring 

✓ 

debug 

1 abel 
msn . t i me 
num.mi ssions 
queue. t ime 
statel 

t i me .V 

NRITES  : 

i d.btry 

id.fo 

state 

id. fdc 
msn . name 
t i me.  V 

FILES  I 

id. mission  in  howitzer 

.queue 

CALLS  : 

art y . t i me 

t racer 

SCHEDULES 

e •• 

• 

guns.fi  ring 

SCHEDULED 

BY  : 

fdc .processing 

complexity  I Constant  execution  time  and  storage 
requi rements. 
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CHG. SEC. SEARCH 


■NUMBER 

parameters  : 


LOCAL  VARIABLES  : 

a 

zyx 

GLOBAL  variables  : 
blue 
css 

mv.stata 
pi  .c 

CALLS  : 

set .sector 


BYTES  OBJECT  CODE  : 1304 


color 

cTi  r .of  .mvmt 
pri  .di  r 


uni f orm.  f 


CALLED  BY  : 

step. t i me 

complexity  : Constant  execution  time  and  storage 

requi rements. 


COMMO. ATTEMPT 


.NUMBER 

PARAMETERS  : 

f d.  fo 
id. radio 

LOCAL  VARIABLES  : 

i d.  fo 
i d. radi o 

GLOBAL  variables  : 

error .code 
state! 
wai t . t i me 

FILES  : 

i d.ffli ss i on  in  m 

CALLS  : 

arty . t i me 

SCHEDULES  : 

commo. at  tempt 
ooen.radio.net 

SCHEDULED  BY  : 

commo. at  tempt 

complexity  : Constant 

requi rements. 


BYTES  OBJECT  CODE  : 1096 

i d.mi ssi on 

i d.mi ss i on 
time 

Kdle 
t i me.  V 

n .queue 

t racer 

f dc .orocess i ng 

execution  time  and 


I i 

I ; 

4 : 

I 

I 

storage  * 


COMMO.PASS.TGT 

NUMBER  BYTES  OBJECT  CODE  : «88 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 

bai  m 
r 

GLOBAL  variables  I 
bwd. I ook 
foe 

op •rng 
pi  t 


aim 
1 ose 


t icat  .value 
f wd. 1 ook 
pet . vi s 


CALLS 


df  St 

sight 


I oc 


CALLED  BY  : 

t72. tactics 

complexity  : Constant  execution  time  and  storage 

requl rements. 

remarks  : This  routine  returns  the  value  of  ' aim  to  the 
calling  routine. 


COMPUTE 


1 

-NUMBER 

BYTES  OBJECT  CODE 

* 

1 ■ 

PARAMETERS  : 

f .pcvi s 

pc.vi s 

1 

sh.t 

tgt  .t 

1 

LOCAL  VARIABLES  : 

11 

addaf 1 

addel 

E' 

daf 1b{as 

def 1 sig 

r 

a1 bf  as 

el  sig 

i- 

f .pcvis 

- i 
✓ 

< o 

J 

p 

k 

1 

|- 

PCaVi S 

r 

4' 

sh.t 

tgt  .t 

val 

H 

‘ 

GLOBAL  VARIABLES  : 

accht 

aceke 

1 

acemb 

acems 1 

addon 

bm.mov 

' 

1 

ht .mov 

pro  jo 

-i 

sod 

won. type 

4 

X .currant 

V .current 

WRITES  : 


CALLS  : 


di  St 
m { n • f 
t rune • f 


geom 

subcal 


CALLED  BY  : 

i mpact 

complexity  : Constant 
rsqui ramants. 


axecut i on 


t i ma 


and 


storage 


CONVERT. BACK 

NUMBER  BYTES  OBJECT  CODE  : 712 

parameters  : 

a 

LOCAL  variables  : 

a pf.int 

GLOBAL  VARIABLES  : 

c. bar 
daf num 

d. num 
micro 
p.hat 
pi ow.cond 
sod 
t .spd 

X .ct 

y. ct 

z. ct 

CALLS  : 

pop.a.ml ne 

CALLED  BY  : 

loc 

complexity  : Constant  execution  time  and  storage 

requi rements . 


cbar 

d.1  r .of  .mvmt 

m.det 

mlne.det 

pi  .c 

p.v 

1 1 me. V 
V .ms 

X .current 

y . current 

z.  current 


DEFEND 


• NUMBER  BYTES  OBJECT  CODE  : 680 

PARAMETERS  : 

a 

LOCAL  VARIABLES  t 

a 

GLOBAL  VARIABLES  : 

a1 1 ve.dead  . 
def num 
mv. state 
p{  «c 
spd 

t i ma.  V 
wpn.type 

CALLS  : 

d1 smount .dragon  hider 

set .sector 

called  by  : 

t oc 

complexity  : Constant  storage  and  execution  time.  I 


ap. tow 

name 
or i .di r 
target 
t .spd 


DETECT 


NUMBER  BYTES  OBJECT  CODE  : 792 


parameters  : 

a 

LOCAL  VARIABLES  : 

a 

Mhoeal 1 ad 

GLOBAL  VARIABLES  : 

a1 i va.daad 


CALLS 


critical .value 
fa 

fkl  1 1 

line .of. sight. exists 


1 1 St .update 
proximl ty. detect 
t racer 


bud. I ook 
'def  num 
f Ip 

f wd. I ook 
pct.vis 


1 oc 
sight 


SCHEDULED  BY  : 

Impact  step. time 

complexity  : Constant  storage  and  execution  time. 

IMPROVEMENTS  : Delete  the  variable  whocalled  • declared  but 
unused. 


OF.CHG 


NUMBER  BYTES  OBJECT  CODE  : 496 


parameters  : 

a 


LOCAL  VARIABLES  : 


a 

GLOBAL  variables  : 

c 

a1 i va.daad 

color 

daf nuffl 

CALLS  : 

hidar 

SCHEDULED  BY  : 

^pd 

bug.chack 

dr .mount 

1 aava.cKack 

1 oc 

complexity  : Constant  storaga  and  axacution 

DISMOUNT. DRAGON 

NUMBER 

parameters  : 

a 

LOCAL  variables  : 
a 

GLOBAL  VARIABLES  : 

BYTES  OBJECT  CODE 

daf nuffl 

ha. dragon 

m2 

mv. state 

name 

oi  .c 

pi  t 

pi t .uni t 

pri  .dir 

tank 

target 

wpn.typa 

X .current 

CALLS  : 

y .current 

hidar 

sat .sector 

CALLED  BY  : 

defend 

1 oc 

744 


complexity  : Storaga  reeiul  ramants  ara  constant  but  execution 
tima  is  I i naar I y, daoandant  on  tha  numbar  of  tanks 
in  p) t .uni t . 


DIST 


NUMBER  eyres  object  code  : 


PARAMETERS  : 

xl 

vl 

LOCAL  VARIABLES  : 

di stance 
x2 

y2 

CALLS  : 

sqPt . f 
called  by  : 

arty • { mpact 
commo.attempt 
error 
fire 
{ mpact 

complexity  ; Constant 


xa 

y2 


xl 

yl 


assessment 
compute 

f dc .processing 
quns.f i rinq 
new. 1 ocat i on 

storage  and  execution  time. 


REMARKS 


Returns  the  value  of  distance  to  the 
rout i ne. 


lai 

C II  ■■II  . 


1 


I 


I 


1 


ailing 


i 

I 


DOING. CLUSTERS 

NUMBER  BYTES  OBJECT  CODE  : 5048 


parameters  : 


WRITES 


CALLS  : 


id.fo 

name. pri ori ty 

pri .value 

[ABLES  : 

a 

angle 

b 

di  r 

i 

a 

• 

o 

j 

■ > 

1 

m 

n 

name. priori ty 

prt . val ue 

s 

tank 

total .clusters 

X 

y 

IIABLES  : 

at i ve.dead 

b.org.al i ve 

box. tolerance 

c 1 usters 

c .number .array 

debug 

di r .of .mvmt 

fo.max . range 

fo. min. range 

1 i St 

name 

o 1 d.c 1 uster .number 

sod 

state4 

target 

X .current 

y .current 

c 1 usters 

i 

i d . f p 

abs.f 

arctan. f 

cos.  f 

di  m.  f 

1 oc 

s i n.  f 

e 

e 

updete.c 1 uster 

complexity  : Storage  Is  constant  but  execution  Is  dependent 
on  the  product  of  the  site  of  the  target  list  and 
the  total  number  of  clusters. 

REMARKS  : Returns  the  values  of  name.ori or i ty  and  pri. value 
to  the  calling  routine. 
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A;; 


OR. MOUNT 


•NUMBER  BYTES  OBJECT  COOE  : U92 

PARAMETERS  t 
LOCAL  VARIABLES  ; 


a 

iii 

GLOBAL 

VARIABLES  : 

ap.tow 

daf num 

tip 

- ha. drag 

m2 

nTv. state 

na«a 

pi  t 

pi t .uni t 

tank 

targat 

t i me. V 

t .tod 

won. type 

* .currant 

y. currant 

CALLED 

BY 

a 

a 

bug.cHack 

1 eave. check 

SCHEDULES 

a 

a 

df .cbq 

a 

COMPLEXITY 

’ : Exacution  tima  inereasas  linear  with  number 

tanks  in  pit. unit 

with  wpn.tyoe  s 6 and 

ha.drag(tank)  gt  0 and 

fir(tank)  ne  1.  Storage  is 

constant . 


WH-'? 


PARAMETERS  : 

i d.bt  py 
id.fo 


END. OF. MISSION 

NUMBER  BYTES  OBJECT  CODE  : 270a 


id.fdc 
id. mi ssion 


LOCAL  VARIABLES  : 

estimate.of .t ima 
id.fdc 
i d.mi ssion 
t i ma 

GLOBAL  VARIABLES  : 

amt .act i ve.msns 
bt  ry 
f i St 

holding. msns 
I abal 
msn.nama 
msn.t i me 
new.  1 ocat i on 
queue. si ze 
state! 
t i me  . V 


WRITES 


FILES  : 


REMOVES 


CALLS  : 


f i St 

id.fdc 

msn.nama 


id. mission  in  msn. queue 


id.btpy 
id.fo 
t ime 


amt .msns. f i red 
debug 

howi tzar .queue 
mi ssion 

my . radio 
num.adj .rounds 
queue. t ime 
St . f i ri ng 
wh  i ch • vol ley 


i d.bt  ry 
id.fo 
t i me. V 


id. mission  from  howi tzar. queue  and  holding. msns 


arty. time 


SCHEDULES  : 

f o.not .busy 
open.radio.net 

SCHEDULED  BY  : 

arty • i mpact 


t racer 


guns . firing 


error 


complexity  : Constant  execution  and  storage  requirements. 
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r 

► 

\ 

I 

t 


f. 

i 

r 

i 


I 

t 

t 

[ 


ERROR 

NUMBER  BYTES  OBJECT  CODE  : 9afl 


parameters  : 

ans 

id.fdc 
id*mi ssion 

LOCAL  VARIABLES  : 
ans 

id.fdc 
id .mi ssion 
sig.y 
xdi  f 

x. normai .error 

y .  i mpact .point 

GLOBAL  VARIABLES  : 

amfflun i t i on . t ype 
error .code 
rn.st  ream 
X . future. 1 oc 

CALLS  : 

di  St 

normal .f 

posi t ion .update 


i d.bt  ry 
id.fo 


i d.bt  ry 
id.fo 
sig.x 
X tank 

X . i mpact .point 
ydi  f 

. V .normal .error 


ca) i ber 

gt . f i nal . 1 oc 

theta 

y. future. 1 oc 


new.coordi nate. system 

parameters 

tracer 


CALLED  BY  : 

arty. impact 

SCHEDULES  : 

end.pf .mission 

complexity  : Constant  execution  and  storage  requirements. 


I 

I 

r 
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FA. 1. MAIN 


t 


NUMBER  BYTES  OBJECT  CODE  : 4936 


LOCAL  VARIABLES  : 
i 
k 
m 

GLOBAL  VARIABLES  : 

amt .ammo. types 
amt .cal {bars 
amt • f f e. vol 1 eys 
amt .red.batterys 
b.num.a) i ve 
box. tolerance 
cutof  T • t i me 
di spl acement 
f o .max . range 
fo. vehicle 
I argest .num.wons 
max .number .of .m i ss i 
max . range 
n. battery 
n . f o 
n.radio 
num.he* 1 eft 
p*punch 
rate.of • f i re 
r .num.al i ve 
r .org.al i ve 
si gma.dpicm 
travel .time. array 
X .cuml 
y .cur  1 


j 

1 


amt .blue. batterys 
amt. fa. time. deltas 
amt.mr) 

" art  y .pk . t abl e 
b. org.al i ve 
colorl 
debug 
d. radi us 
fo.mi n. range 
fwd.obs.msn. tolerance 

s.per . fo 

mi ss.tol erance 
n.fdc 

no . range .bands 
num.doi cm. left 
num .guns 
range. bands 
red. 1 .constant 
rn . St  ream 
sal  VOS 

tgt .acg. error 
t r . t i me 
X .cur2 
y .cur2 


I 


1 


I 


I - 

‘i 
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FA. 1. MAIN  (cont) 


READS 


amt .ammo. types 

amt .cal Ibers 

amt.f fe.vo) leys 

amt.red.batterys 

box .tol erance 

cutof  ^ • t i me 

dl spl acement 

f o .max . range 

f o. veh i c I e 

1 argest .num. wons 

max .number .of .mi ss i ons 

max • range 

n. battery 

n . f o 

n. radio 

num. he. I eft 

p. punch 

rate. of .fi re 

s i gma .dpi  cm 

travel .time. array 

x.curl 


amt.blue.batterys 

amt. fa. time. deltas 

amt .mr 1 

arty. pic. table 

colorl 

debug 

d. radi us 

fo. min. range 

fwd.obs.msn.tol erance 

per. fo 

mi ss . tol erance 
n.  fdc 

no. range. bands 
num. dpi  cm. 1 eft 
num.guns 
range. bands 
rn. stream 
tgt .acq. error 
t r . t i me 
y .curl 


CREATES  : 

battery  fdc 

fo  radio 


RESERVES 


array .detect 

clusters 

di sol acement 

fa. time. del tas 

1 ethal .radius 

red .pi anned. fires 

t i me .1 ast .c I uster .update 

travel .time. array 


arty. Pk. table 
c .number .array 

f o . vehc 1 e 
rangc.bands 
s i gme .dpi  cm 
tgt .acq. error 


RELEASES  : 

prepl anned 


CALLS  : 

prepl anned 


CALLED  BY  : 

me  i n 

complexity  : Linear  on  n.fdc»  n.battervf  amt .ammo. types 

amt .cal ibersr  amt.blue.batterys  * num.guns 
amt. calibers  * no. range. bands 

IMPROVEMENTS  : Reads  num.dpicm.  1 ef t then  sets  to  0. 


ia7 


I 


FA. 2, MAIN 


NUMBER  BYTES  OBJECT  CODE  : 5a72 


LOCAL  VARIABLES  : 


GLOBAL  variables  : 

amt .ammo. types 

amt, cal Ibers 

amt . f f e.vol 1 eys 

amt .red.batterys 

b.org.al rve 

cutof  f • t i me 

d. radi us 

fo.max • range 

f o »veh i c 1 e 

1 argest .num.Mons 

max .number .of  «mi ss i ons . 

mi ss.tol erance 

n.  f dc 

no, range .bands 
n. tanks 
poi nt i ng. to 
rn .St  ream 
rrrpoi nt 


amt. blue. batterys 
amt. fa. time. deltas 
amt .mr 1 

• ^ arty.pk.tab1 e 
box . tol erance 
debug 
fa 

f o .mi n .range 
fwd.obs.msn. tol erance 
1 ethal . radi us 

per. fo 

n. battery 
n.  fo 
n . radi o 
pi  .c 
P. punch 
r .org.al i ve 
type 


MRITES 


amt .ammo. types  amt. blue, 

amt.calibers  amt.fa.ti 

amt . f f e.vol 1 eys  amt.mrl 

amt .red.batterys  b.org.al i 

box . tol erance  cutoff. ti 

debug  d. radius 

fo. max. range  fo.min.ra 

fwd.obs.msn. tol erance  largest. n 

max .number .of .mi ssions.per.fo 
mi ss.tol erance  n. battery 

n.fdc  n.fo 

no. range. bands  n. radio 

n. tanks  p. punch 

r.org. alive  rn. stream 


amt. blue. batterys 
amt. fa. time. deltas 
amt.mrl 
b.org.al i ve 
cutoff .time 
d. radi us 
f o .mi n . range 
1 argest .num.wpns 


FA, 2. MAIN  (cont) 


CALLS  : 


sqrt.f 


CALLED  By  : 

main 


SCHEDULES  I 

ped.anty . f i ras 


update. c 1 uster 


complexity  : Linear  on  n,fo/  amt.calibers  * amt .ammo. types  * 
9»  amt . red.batterys  - a'mt.mrl 


IMPROVEMENTS  : Combine  major  loops. 

FA. TGT. ERROR 

NUMBER  BYTES  OBJECT  CODE  : ai6 


PARAMETERS  : 

a 


LOCAL  VARIABLES  : 
a 


GLOBAL  VARIABLES  : 

rn. stream 


CALLS  : 


t racer 


1 oc .error 

1 oc .error 

tgt .acq. error 

uni  form. f 


called  by  : 

new. location 


complexity  : Constant  execution  and  storage  requirements. 


REMARKS  : This  routine  returns  the  value  of  loc. error  to  the 
calling  rout i ne. 


1«9 


:1 


1 I 


1 

1 

FOC. PROCESSING. 

1 

NUMBER 

BYTES  OBJECT  CODE  : 3«2a 

1 

parameters  : 

1 

i d*  fo 

id.mission 

• 

LOCAL  variables  : 

i 

dUf 

i 

id.btpy 

i d.  f 0 

id.ntssion 

j 

k 

1 

1 

m 

• rg 

} 

t i me 

^ type. ammo 

i 

vol 1 eys 

\ 

t 

yy  , 

GLOBAL  VARIABLES  t 

ammuni t f on .type 

amt  .act i ve .msns 

amt . f f e. vol 1 eys 

busy 

debug 

dpi  cm 

error, code 

fwd.obs.msn.tol erance 

gt . f i nal . rg 

gt  . i ni  t { a1  . rg 

ml ssi on 

my . radio 

msn .name 

msn.t 1 me 

n.  fdc 

• 

n.hol di ng.msns 

num.mi ssions 

process 

queue. si ze 

start 

statel 

status 

theta 

t i me.v 

vol 1 eys.to.fi  re 

X .curl 

X .curA 

X . f uture. 1 oc 

y .curl 

y .curA 

y . future. 1 oc 

1 

r 

WRITES  : 

i 

i d.  f 0 

i 

msn.name 

num.mi ssi ons 

i 

queue. si ze 

statel 

time.v 

t 

t 

FILES  : 

id.mission  in  holding, msns  and  msn. queue 

• 

CALLS  : 

arctan.f 

arty .t ime 

- 

• 

di  St 

t racer 

i 
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> 

FOC. PROCESSING  (cont) 


SCHEDULES  : 

check i ng.guns.avai  H bH  i t y 
f o*not (busy 

SCHEDULED  0Y  : 

commo.attemot 

complexity  : Execution  time  is  linear  with  n.fdc  and  storage 
is  constant. 

IMPROVEMENTS  t Combine  all  "for"  loops  into  one. 


1 


I 

t 


! 

i 


5 


f 

i 
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I 
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I 


i 
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final. DEATH 


NUMBER  BYTES  OBJECT  CODE  I 1^241 


PARAMETERS  ; 

a 

LOCAL  VARIABLES  : 
a 

GLOBAL  variables  : 

a1 { ve.dead 
f .d 
fki  1 \ 
hi t .state 
kk  i 11 
inf  k i 1 1 
name 
num.hi t 
t i me.  V 
X .current 
z. current 


WRITES  : 

def num 
f i red. at 
guntube 
k.hi  t 
m.d 
mk  i 1 1 
ncase 
sod 

won. type 
V. current 

CALLS  : 

tall y. hi t .state 

SCHEDULED  BY  : 

atri  t 


def num 
f i red. at 
' guntube 
k . h i t 
m.d 
mk  i 1 1 
ncase 
spd 

wpn.type 
y .cur rent 


f .d 
fki  1 1 
hi t .state 
kki  1 1 
mfki  I 1 
name 
num .hit 
t i me.  V 
X .current 
z. current 


complexity  : Constant  execution  time  and  storage 

requi rements. 


i 

\ 

I 

I 

i 

I 

k 

I 

i 

1 


T 
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FIRE 


NUMBER  BYTES  OBJECT  CODE  : 2232 


parameters 


LOCAL  VARIABLES  : 

a 

1 ose 

stop. count 
GLOBAL  VARIABLES  : 


CALLS  : 


a1 1 ve.dead 

^ b1  ue 

bwd. 1 ook 

check. 1 1 me 

color 

critical .value 

defnum 

foe 

flp 

fkl  1 1 

f wd. 1 ook 

mv . state 

mz 1 . vel 

OP. rng 

pct .v1 s 

pointer 

projo 

range 

scHed 

second .shot 

tgt.sc) 

1 1 me. V 

won. type 

X .current 

y .current 

decrement .anno 

d1  St 

hider 

1 oc 

set . muzzle. vel 

sight 

stop.to.f1  re 

tracer 

* » 
m 

1 mpact 

target .sel ect 

SCHEDULED  BY  : 

t72.tact  tcs 
we.ffli ss 

complexity  : Constant 

requi remants. 


target .select 


execution  tine  and  storage 


FIRST 


NUMBER  BYTES  OBJECT  CODE  : 286 

parameters  : 


LOCAL  VARIABLES  : 


GLOBAL  VARIABLES  : 

mu  range 

wpn.type 

CALLS  : 

t rune. f 

CALLED  BY  : 

lay .load 

l; 

I complexity  : Constant  execution  time  and 

• V requirements. 

\ * 

j FO.  NOT.  BUSY 

> 

NUMBER  BYTES  OBJECT  CODE  : 408 

PARAMETERS  : 

i d.  fo 

LOCAL  VARIABLES  : 

i d.  f o 

GLOBAL  VARIABLES  : 

amt .act i ve. mans  idle 

f status 

I 

SCHEDULES  : 

update. c 1 uster 

i SCHEDULED  BY  : 

I end.of .mi ssion  f dc .proeessi ng 

I complexity  : Constant  execution  time  and 

; requirements. 


i 

! 

i 


storage 


storage  \ 

‘ ; 

■ ' 

I .1 

1 


1 
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• NUMBER 

BYTES  OBJECT  CODE  : 

PARAMETERS  : 

addef 1 

addet 

def 1 bi as 

deft  sig 

al bi as 

et  si g 

f .pcvi s 

pc . vi s 

r 

sh.t 

tgt  .t 

LOCAL  VARIABLES  : 

addef 1 

^ addet 

ai ffldi s 

def  di  s 

def Ibias 

deft  mi ss 

deft  stg 

di  swk 

efkt I t 

efpt 

et  bi as 

et  di  s 

el  mi  s 

et  mi ss 

' et  si g 

emk  i 1 1 

empi 

f .pcv  i s 

fk 

gamma 

i 

i 0 

j 

jo 

k 

kayki 1 1 

kaypl 

kk 

I 

length  

m 

mk 

mo 

mo 

n 

PC . V i s 

p 

ro 

sh.t 

si  ze 

tgt.'t 

turret 

vet 

whoca 1 1 ed 

width 

X .t 

y.t 

GLOBAL  variables  : 

at i ve.dead 

damage. num 

di r.of .myrnt 

hnorm 

j norm 

kki  1 1 

tell 

1el2 

I»31 

tebl 

te7l 

le72 

leSl 

le83 

nopseed 

Ph 

ppojo 

spd 

t ardi m 

veh .type 

wpn.type 

X .current 

y .current 

GEOM  (cont) 

CALLS  : 

abs.f  arctan.f 

atrft  cos.f 

loadn  sin.f 

trunc.f 

CALLED  BY  ; 

compute  ^ 

complexity  : Constant  execution  time  and 

requi rements.  ' ^ 

GET. UP 

NUMBER  BYTES  OBJECT  CODE  : 576 

PARAMETERS  : 


LOCAL  VARIABLES 


bn 

mv • state 
red.al i ve 
target 


GLOBAL  VARIABLES  : 

ao.tow 
def num 
name 
tank 

Mpn.type 

CALLS  : 


CALLED  BY  : 

charge 

complexity  : Constant  execution  time  and 

requirements* 


storage 


storage 


GUNS. FIRING 


NUMBER  BYTES  OBJECT  CODE  : 1768 


parameters  : 

id.btry 

id. fdc 

id.fo 

i d.mi ssi on 

LOCAL  VARIABLES  : 

id.btry 

i d. f dc 

id.fo 

id. mi ssion 

rg 

tof 

type. ammo 

wpn.type 

✓ 

GLOBAL  VARIABLES  : 

ad j . round 

ammun i t i on. t ype 

cal iber 

debug 

gt . f i nal . rg 

msn .name 

my. radio 

now .firing 

t i me.  V 

travel .time. array 

wh i ch . wol 1 ey 

* .curl 

X . future. 1 oc 

y .curl 

y . future. 1 oc 

WRITES  : 

id.btry 

i d. f dc 

id.fo 

msn. name 

t i me. V 

wh i ch • V0 1 ley 

CALLS  : 

di  St 

t racer 

SCHEDULES  : 

arty . i moact 

busy .radi o.net 

open.radio.net 

SCHEDULED  BY  : 

arty. Impact 

cNeckf  ng.guns.avail  abn  4 ty  ^ 
and. of .mi asi on 

complexity  : Constant  execution'  time  and 

requirements. 


storage 
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HIDE 


NUMBER  BYTES  OBJECT  CODE  ; 1536 

PARAMETERS  : 


a 

whoca 1 1 ed 

LOCAL  VARIABLES  : 

a 

whocal 1 ed 

hold 

GLOBAL  VARIABLES  : 

al i ve.dead 
mv. state 

^efnum 

CALLS  : 

hider 

reload 

SCHEDULES 

• 

• 

h { de 

SCHEDULED 

BY  : 

hide 

rel oad 

we.h i t 

we.mi ss 

complexity  : Constant  storage  and  execution  time. 

HIOER 

NUMBER  BYTES  OBJECT  CODE  : 320 


PARAMETERS  : 


LOCAL  VARIABLES  : 

a adef 

aname  wtype 


GLOBAL  VARIABLES  : 


dofnum 

micro 

name 

wpn.type 

2h 

CALLS  : 

• 

mcov 

CALLED  BY  : 

bl .create 

defend 

• 

df  .chg 

di amount .dragon 

f i re 

h i de 

red.creatfr 

target .select 

we.h i t' 

we.mi ss 

complexity  : Constant  storage  and  execution  time. 
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IFV. TACTICS 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 
a 
b 

GLOBAL  VARIABLES  : 
foe 

pi  t .uni t 


• NUMBER  BYTES  OBJECT  CODE 

b 


answer 

2 


352 


CALLS  : 


pi  t 
tank 


uniform, f 


CALLED  BY  : 

target .set  act 

complexity  : Execution  is  linear  on  tank  in  pit. unit 
storage  is  constant. 


and 
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IMPACT 


tJUMBER  BYTES  OBJECT  CODE  : 4408 

PARAMETERS  : 

a i d 

y 


LOCAL  VARIABLES  : 
a 

dt 

r 

whocal 1 ed 

y 


id 

stopcount 

X 


GLOBAL  VARIABLES  : 

a1 i ve.daad 
check .t  f me 
critical .value 
dam.array 
fa 

f i red. at 
fki  I 1 
fwd. 1 ook 
guntube 
k.hi  t 
kki  n 

mfki  1 1 
nifnni 

name 
nuffl.h i t 
pet .vi s 
pro  jp 
spd 

tow. kount 
wpn.type 
y .current 


bwd.look 

CO 

damage .num 
def num 
f .d 
f ip 
foe 
Q • a 

hi t .state 

killer 

m.d 

mki  1 1 

mv. state 

ncase 

pcb. vi s 

pointer 

range 

t i me.  V 

ttt 

X .current 
z .current 


WRITES  : 


def num 

f .d 

f i red. at 

fki  1 1 

Q • anifvi 

guntube 

hi t .state 

k .h i t 

kki  1 1 

m.d 

mfki  1 1 

mk  i 1 1 

name 

ncase 

num.h i t 

pcb.vi s 

pro  jo 

range 

spd 

t i me . V 

ttt 

wpn.type 

X .current 

y .cur rent 

z. current 

1 

! 
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IMPACT  (cont) 


CALLS 


compute 
list .update 
sector .check 
stop.to.fi  re 
tracer 
we.ffli ss 


SCHEDULES 


mr 1 . i mpact 


SCHEDULED  BY 


complexity 


: Constant  execution  time 

requi rements  . 


GLOBAL  VARIABLES  : 

projo  wpn.type 

CALLS  : 

first  max.f 

normal • f 

CALLED  BY  ; 

t72. tactics  target .sal  act 

wa.mi ss 

complexity  : Constant  SHaeution  time  and  storage 

raqui ramants. 

REMARKS  : Returns  the  value  of  time  to  the  calling  routine. 


1 


LEAVE. CHECK 


NUMBER  BYTES  OBJECT  CODE  : 9768 

PARAMETERS  : 

a 

local  VARIABLES  : 


a 

b 

bb 

be 

cb 

cc 

» J 

i k 

i m 

■ 

GLOBAL  VARIABLES  : 

ap.tow 

bn 

color 
de  f num 
hasty 
mv.state 
pi  t 
red 
tank 
t .dead 
t .spd 
won. type 

CALLS  : 

dr .mount 
t rune . f 

CALLED  BY  : : 

tal 1 ^.h 1 1 .state 


b 1 ue 

CO 

comp. uni t 

fa 

m2 

name 

p I t .un i t 
red. a 1 i ve 
target 
t i me. V 
upper . 1 ower 


1 oc 


SCHEDULES  ; 

charge 


df .chg 


COMPLEXITY  : Execution  time  depends  on  tanks  in  comp. unit  * 
tanks  in  pit. unit  and  storage  is  constant. 


i 

[ 


i 
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LIST. UPDATE 


PARAMETERS  : 

a 

I ose 

LOCAL  VARIABLES 


NUMBER  BYTES  OBJECT  CODE  : IBUO 


whocal 1 ed 


a 

b 

count 

f 1 ag 

i 

1 osa 

si  za 

tfhocal  1 ad 

GLOBAL  VARIABLES  : 

a1  i ve.daad 

fa 

Hst 

tamp.tgt 

RESERVES 

Su. 

RELEASES 

'h.. 

CALLS  : 

d1  m.  f 
uni f orm.f 

IB i n.  f 

CALLED  BY 

a 

a 

datact 

i mpact 

proxiai ty. da tact 

targat .sal  act 

SCHEDULES 

a 

a t, 

target .sal  act 

uoc 


I 

i 

J 

i 
i 

NUMBER  BYTES  OBJECT  CODE  : 1096  * 

PARAMETERS  : j 

tank  1 

LOCAL  VARIABLES  : ' 

tank 


GLOBAL  VARIABLES  : 


a1 1 ve.dead 

blue 

CO 

color 

def num 

list 

fflki  11 

m.red.al i ve  1 

mv.state 

name 

pi  t 

red 

spd 

Mpn.typa 

target 

REMOVES  t 

tank  from  red.al 

iver  comp. unit  and  pit. unit 

RELEASES 

• 

list 

CALLS  : 

convert .back 

defend 

param.set 

1 

CALLED  BY 

• 

• 

i 

assessment 

commo.pass.tgt 

detect 

di smount .dragon 

doing. clusters 

f i re 

get .UP 

i mpact 

1 eave. check 

1 oc .update 

mr 1 . i mpact 

position. update 

red.arty.fi  res 

stop.si mu  1 at i on 

t72.tact i cs 

target .select 

SCHEDULES 

• 

• 

: 

df  .chg 

i 

< 

s 

complexity  : Constant 

requi rements. 

execution  time  and  storage  j 

1 

LOC. UPDATE 


NUMBER  BYTES  OBJECT  CODE  : 38« 

LOCAL  VARIABLES  : 

tank 

GLOBAL  VARIABLES  : 

alive.dead  delta. t 

CALLS  : 

1 oc 

SCHEDULES  : 

loc.uodate 

SCHEDULED  BY  : ' 

loc.update  red.create 

complexity  : Constant  execution  time  and  storage 

requi rements. 
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MAIN 


NUMBER  BYTES  OBJECT  CODE  : 5R28 


LOCAL  variables  : 


READS  : 


cnum 

i 

j 

pnum 

RUBLES  : 

area 

b.area 

be .count 

b. num.al i v 

b.pct .att 

bt  1 1 me 

case 

■ c*bar 

cdt ime 

company .co 

constant 

cri t ical .v 

d.nun 

dam. array 

def .time 

del ta.t 

dsl 

ds2 

guntube 

hasty 

{ .dead 

i t .dead 

j norm 

1 1 n 

1 ines.v 

m.det 

mmm 

mu 

ncase 

n .company  .1 

nnn 

norseed 

n.pl atoon. 1 eader 

pea .unc 

pea. vi s 

pcb.unc 

pcb. vl s 

P.hat 

pi atoon. 1 eader 

pi  .c 

P.V 

qa 

r.area 

rc .count 

r .num.al 1 ve 

r.pct .att 

seed.v 

s 1 . t i me 

s2 . 1 1 me 

steps 

target 

t .dead 

temo.tgt 

tgtsc 1 

ttt 

upper. 1 owei 

V .ms 

w.k.c 

X .ct 

X .StOD 

y.ct 

y .stop 

z.ct 

zh 

b .num.al i ve 

b .pct .att 

cnum 

del ta.t 

dsl 

ds2 

guntube 

mu 

ncase 

onum 

r.num.al 1 ve 

r .oct .at  t 

seed.v 

upper . 1 ower 

X .stop 

y .stop 
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MAIN  (cont) 


NRITES 


b.pct.att 
norsaad 
upper. 1 ower 
y .stop 


quntube 
r .pet .att 
X .stop 


CREATES 


every  pi atoon • 1 eader  every  company .commander 


bbbpol nt 
dam. array 
dsl 

1 .dead 
ffl.det 

pca. unc 

pcb. unc 
p.hat 

P.v 

rrrpoint 
t .dead 
tgtsc 1 


c .bar 
'd.num 
ds2 

1 t .dead 
mu 

pca. vi s 

pcb. vi  s 
pi  .c 

dd 

target 
temp.tdt 
V .ms 
y .ct 
rh 


CALLS 


fa.c.main 
1 oadn 
pes2 
pes4 

set .sector 


SCHEDULES 


new. forces 
stop.si mul atlon 


attri tion. check 
step. t i me 
stop. simulation 


complexity  : Execution  is  dependent  on  the  number  of  tanks. 

Storage  is  dependent  on  the  number  of  platoon 
leaders#  the  number  of  company  commanders  and  the 
number  of  elements  in  r.num.alive  and  b.num. alive. 


REMARKS  : Main  routine  starts  the  simulation 


MRL. IMPACT 


% 

%. 

V 

f 

r 

t 

i 

i 

i 


f 


i 


i 


1 ! 


NUMBER 

parameters  : 

X.  I oc 

LOCAL  VARIABLES  : 

id.bt  ry 
no.mens • f i red 
red. 2. constant 

X 

y . )oc 

GLOBAL  VARIABLES  : 

a1 i ve.dead 
ca) iber 
def num 
f i red. at 
foe 

h{ t .state 

k.hU 

rn.d 

mki  1 I 

ncase 

num. he. I eft 
red. 1 .constant 
tank 

Mpn.type 
y .current 

WRITES  : 

cal f ber 
f.d  - 

fki  n 

hi t .state 
kki  I I 
mf ki 1 1 
name 
num. hi t 
t i me.  V 
X .current 
2. current 

CALLS  : 

abs.  f 

1 oe 

uni  form. f 

SCHEDULED  BY  : 

impact 


BYTES  OBJECT  CODE  : 2568 


y . 1 oc 


i d. red.bt  ry 
Pk 

type. ammo 
X . 1 oc 


arty. pk. table 

debuq 

f.d 

fki  1 1 

guntube 

kki  n 

mf  k i 1 1 
name 

no.msns . f i red 

num.h  i t 

spd 

t i me.  V 
X .current 
t. current 


def num 
f i red. at 
guntube 
k .h i t 
rn.d 
mk  i 11 
ncase 
spd 

type. ammo 
y .current 


at  ri  t 
t racer 


I 


I 

! 


S 
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MRL. impact  (cont) 


complexity  : Execution  time  is  linear  on  tanks  in  blue.alive 
and  storage  is  constant. 


REMARKS  : Local  variable  no.mens.fi  red  should  be 

no.msns. f i red. 

NEW. COORDINATE. SYSTEM 


NUMBER  BYTES  OBJECT  CODE  : 88 


parameters  : 

angle 
yol  d 

LOCAL  VARIABLES  : 

angl  e 
xol  d 
yol  d 

CALLS  : 

cos.f 
t racer 


CALLED  BY  : 

assessment 


xold 


xnew 

ynew 


sin.f 


error 


complexity  : Constant 

requi rements. 

REMARKS  : Yielding  xnew  and 


execut i on 

ynew 


time  and  storage 


NEW.FO 

NUMBER  BYTES  OBJECT  CODE  : «56 


PARAMETERS  : 

a 

LOCAL  VARIABLES  : 

blue. alive  co 

fa  pit.ldr 

tank  type 

SCHEDULED  BY  t 

i mpact 

complexity  ! Execution  time  is  linear  on  tank  in  blue. alive 
with  co(tank)  s co(a)f  until  tank  s pi 1 1 dr ( t ank ) . 
Storage  requirements  are  constant. 


NEW. FORCES 


PARAMETERS  t 

start 

LOCAL  VARIABLES  : 

start 

GLOBAL  VARIABLES  : 
name 


NUMBER  BYTES  OBJECT  CODE  : 128 


stop 


stop 


RELEASES  : 


CALLS  : 


bbbpoi nt 
rr rpo 1 nt 


rad.create 


red.create 


SCHEDULED  BY  : 

main 

complexity  : Constant  execution  time  and 

requi rements. 


storage 


t 

I 
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I 

( 


NEW. LOCATION 

NUMBER  BYTES  OBJECT  CODE  : I38a 


PARAMETERS  : 

a 

i d.mi ssl on 

LOCAL  VARIABLES  : 
a 

distance 
err. 2 
err  .4 
err  .6 
err.0 
id.fdc 
i d.mi ssi on 
X . i 

X .3 

GLOBAL  VARIABLES  : 

di r .aoparent 
error .code 
sod. aoparent 
X .cur« 
y .cur4 

CALLS  : 

arctan.f 
di  St 

posi tion. update 
t racer 

CALLED  BY  : 

arty. impact 

complexity  : Constant 

requ i rement  s . 


del .time 


del .time 
err  . I 
err  . 3 
err  .5 
err  . 7 
i d.bt  ry 
i d.  f o 
tank 

X . 2 
XX 


di rect i on 

mission 

type 

X . future. 1 oc 
y . future. } oc 


cos.f 

fa.tgt .error 
si  n.  f 


update. c luster 
execution  time  and 
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storage 


NEM. MISSION 

>IUMBER  BYTES  OBJECT  CODE 


ia32 


PARAMETERS  : 

i d*  fo 

name.priori ty 
LOCAL  VARIABLES  : 


priority 

GLOBAL  VARIABLES  : 

amt . i n .c i usters 
di rect ion 
fo.tgt .range 
mission 
no.c 1 usters 
pri .of .c 1 uster 
t i me.of .update 
X .curA 


WRITES 


CREATES 


CALLS  : 


called  by 


a 

i d.  f o 
speed 
y .curA 


mission 


di  st 


priority 


i d.  f o 

name. pri or i ty 


clusters 
fist 
] count 
msn  .name 
poi nt i ng. to 
speed 
t i me . V 
y .cur A 


di rect i on 
msn .name 
x.curA 


t racer 


update.c 1 uster 


complexity  : Constant 

requi rement  s . 


execution 


t i me 


storage 


OPEN.RADIO.NET 


' NUMBER  BYTES  OBJECT  CODE  : 2a0 


parameters  : 

{ d. radi o 

LOCAL  variables  : 

id. radio 

GLOBAL  VARIABLES  : 

States 

CALLS  : 

t racer 

SCHEDULED  BY  : 

arty. impact  commo. attempt 

end. of •mi ssi on  guns. firing 

complexity  ! Constant  execution  time  and  storage 
regui rements. 


17a 


MdiiMMHilll 


PARAM.SET 


NUMBER  BYTES  OBJECT  CODE  : 920 


PARAMETERS  : 


LOCAL  VARIABLES  : 


weaoonry 


aname 


GLOBAL  VARIABLES  : 

c .bar 
def num 
d.num 
micro 
mv . 1 1 me 
p.hat 
pi  .e 
p.v 

1 1 me . V 
V .ms 
X .ct 
y .ct 
z.ct 
zh 


^cbar 
di r .mvmt 
m.det 
mi ne.det 
name 
pi .hat 
pi ow.cond 
spd 
t .spd 
wpn.type 
X .current 
y .current 
z .current 


CALLS  : 


move 


CALLED  BY  : 

1 oc 

complexity  : storage  requirements  and  executicn  time  are 
constant . 


t 

t 

I 


PARAMETERS 


NUMBER  BYTES  OBJECT  CODE  : 1128 


PARAMETERS  : 

j 

pg 

local  variables  : 

count 
del t8.2 
i 
k 

slg.df 

GLOBAL  VARIABLES  : 

no.range.bands 

CALLS  : 

tracer 

CALLED  BY  : 

assessment 


k 

type.ammo 

del t a.  1 
f ract i on 
j 

i*g 

s i g. rg 
range. bands 


error 


complexity  : execution  time  is  linear  depending  on  the 
number  of  range  bands.  Storage  is  constant. 

REMARKS  : This  routine  returns  the  value  of  sig-rg  and 
sig.df  to  the  calling  routine. 


1 


POP. A. MINE 


• NUMBER  BYTES  OBJECT  CODE  :1760 

parameters  : 


tnk 

type 

LOCAL 

VARIABLES  : 

efki  1 1 

emk i 1 1 

jo 

kay k i 11 

tnk 

type 

M hoc a 1 led 

GLOBAL 

VARIABLES  : 

damage  .num 

dam .array 

detnum 

f .d 

f i red. at 

fki  1 1 

guntube 

hi t .state 

k . h 1 1 

kki  1 1 

m .d 

mini eth 

mf  k i 1 1 

mk  { 1 1 

name 

ncase 
pi ow.cond 

num.h  j t 

spd 

t ime.v 

wpn.type 

X .current 

y .cur rent 

z .current 

WRITES 

• 

def  num 

f ,d 

f i red. at 

fki  1 1 

guntube 

hi t .state 

k.hij 

kki  1 1 

m.d 

m f k i 1 1 

mk  i 1 1 

name 

ncase 

num .h i t 

spd 

t i me  . V 

wpn .type 

X .cur rent 

y .current 

z .current 

CALLS 

• 

• 

at  r i t 

CALLED 

BY  : 

convert .back 

complexity  : Storage  requirements  and  execution  time  are 
constant . 


position. UPDATE 

NUMBER  BYTES  OBJECT  CODE  : 1104 


PARAMETERS 


LOCAL 


CALLS  : 


CALLED  BY 


a 

i d.mi ssi on 

[A8LES  : 

a 

i d.  f o 

i d.mi ssi on 

spd.bar 

tank 

X .bar 

y .bar 

1 TABLES  : 

✓ 

b.org.al i ve 

c .number .ar 

di recti  on 

f i St 

name 

no. clusters 

red.al i ve 

spd 

speed 

state4 

t i me. V 

t .pos i t i on 

X .cur rent 

X .cur4 

y .current 

y .cur4 

cos.f 

1 oc 

si  n.  f 

t racer 

e 

• 

arty . i mpact 
new. location 

error 

complexity  : Storage  requirements  are  constant.  Execution  is 
linear  on  tanks  in  red.alive. 
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PREPLANNED 


NUMBER  BYTES  OBJECT  CODE  : 1008 


PARAMETERS  : 


LOCAL  VARIABLES  : 


GLOBAL  VARIABLES  : 

ped.pl anned.fi  res 


CALLED  BY  ; 

fa. 1 .main 


complexity  : Constant  execution  time  and 

requi rements • 


PRINT 


NUMBER  BYTES  OBJECT  CODE  : 336 


parameters: 

i d.mi ssion 


LOCAL  VARIABLES  : 

debdg 
rad. err 
X. future. 1 oc 
V • future. 1 oc 


id. mi ssion 
X .cur4 
y .cur4 


WRITES  : 


rad. err 


CALLS  : 


di  St 


CALLED  BY  : 

arty . i mpact 


assessment 


complexity  : Constant  execution  time  and 

requi rements. 


storage 


storage 


1 

PRINTl 

NUMBER  BYTES 

OBJECT  CODE  : 1124 

■ PARAMETERS  : 

K 

i d*mi ssi on 

1 LOCAL 

VARIABLES  : 

K 

i 

i d.  f 0 

i d«m i ss I on 
tank 

t 

GLOBAL 

VARIABLES  : 

b.org.ai i ve 

c. number. array 

debug 

fist 

name 

no. cluster  | 

pd. offset 
red.al i ve 

state4  1 

tank 

x.cjr4 

X .current 

X. future. loc  || 

y.cura 

y . future. 1 oc 

y ecurrent  'i 

■ 1 
1 

WRITES 

• 

• 

j 1 

i 

^ 1 

name 

rd. offset  j 

' 

X .cur4 

X. current  i 

X . f uture. 1 oc 

y .cur4 

y .current 

y. future. loc 

CALLEO 

BY  : 

arty • i moac  t 

assessment 

1 complexity  : Execution  time  is 

linear  on  tank  in  red.al ive  i 

and  storage  is  constant. 

! 

i 

• 

1 

1 

1 

■ 
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PRIORITY. AND. ROUND. SELECT 


parameters  : 

a 

LOCAL  VARIABLES 
a 
b 

j 

pnd 


NUMBER  BYTES  OBJECT  CODE  : 


b 


answer 

\ 

P 

threshold 


GLOBAL  VARIABLES  : 
bl  u« 
dsl 

won. type 

CALLS  : 

ammo. check 


color 

range 


t rune,  f 


1336 


CALLED  BY  : 

target .sel ect 

complexity  : Constant  execution  time  and  storage 

requi rements. 

remarks  : Returns  the  value  of  o and  rnd  to  the  calling 
routine. 


18» 


a b 

Mhocalled  x.sampla 

y .samol e 


GLOBAL  VARIABLES  : 

a1 i va.dead 
color 
pi t .uni t 
* .current 

CALLS  : 

abs.f  1 i St .update 

CALLED  Br  : 

detect 

complexity  : Execution  time  is  linear  on  tank  in  pit. unit 
and  storage  is  constant. 


RED. CREATE 


•NUMBER  BYTES  OBJECT  CODE  : 2408 


PARAMETERS 


LOCAL  VARIABLES  : 
i 

GLOBAL  VARIABLES  : 

ap.tow 
bbbpoi nt 
bn 

c .number. array 
cocdr 

di r.of .mvmt 


array .detect 
%c  .count 
b.num.al i ve 

CO 

def num 
list 


max .number .of.missions.oer.fo 


reads  : 


mv  .state 
n.fo 
pi  .c 
pTt 

pointer 
spd 
target 
wpn. type 
y .current 


On 

cocdr 
pi  t 

won, type 
y .current 


name 
op. rng 
pi ow.cond 
pi 1 1 dr 
pri .di r 
tank 
t i me. V 
X .current 


CO 

name 
o 1 1 1 dr 
X .current 


CREATES 


FILES  r 


tank 


tank  in  tanksr  red.alive»  comp. unit  and  pit.unit 


RESERVES  : 

array. detect  c .number. array 


RED. CREATE  (cont) 


RELEASES  : 

array .detect 

CALLS  : 

basic. 1 oad 
set .sector 

CALLED  BY  : 

new. forces 

SCHEDULES  : 

I oc .uodate 

complexity  : Execution  is  dependent  on  input  parameters  a 
and  b»  main  loop  will  be  executed  b*a>l  times  per 
invocation.  Storage  is  dependent  on  be. count# 
n.fo  and  max .number. of .mi ssions. per. fo. 


c. number. array 

h i der 


I 


t 


RED. ARTY. FIRES 

1 

i 

NUMBER 

BYTES  OBJECT  CODE  : 3368 

' 

« 

PARAMETERS  : 

1 

<d.r«d.btry 

i terat i on 

1 

. 

LOCAL  VARIABLES  : 

■ 

i 

i d. red.bt  ry 

i terat ion 

ok 

red*2.eonstant 

type. ammo 

x 

GLOBAL  VARIABLES  : 

a1 i ve.dead 

arty. pk. table 

b1 ue.al i ve 

cal iber 

def num 

f .d 

f i red.at 

fki  1 1 

foe 

guntube 

hi t .state 

k.hi  t 

kki  1 1 

kount 

tn.d 

mf  k i 1 1 

ink  i n 

name 

ncase 

no.fflsns • f i red 

num.dpicm. 1 eft 

nuffl.guns 

num. he. left 

- 

num. hi t 

red.p1 anned. f i res  rn. stream 

j 

sal  VOS 

spd 

tank 

t i me. V 

i 

won. type 

X .current 

y .cur rent 

2 .cur rent 

fl 

WRITES  : 

i 

cal i ber 

def num 

i 

f .d 

f i red.at 

fki  1 I 

guntube 

hi t .state 

k . h i t 

kki  1 1 

m .d 

mfki  1 1 

mki  1 1 

name 

ncase 

num.h i t 

spd 

t i me. V 

type. ammo 

X .current 

y .current 

z. current 

1 
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! 

i 

i 

II. 

RED. ARTY. FIRES  (cpnt) 


CALLS  : 

SCHEDULES 

SCHEDULED 

complexity 


at  pi  t 
t racer 


1 oc 

uni  form. f 


red.arty.fi  res 
BY  : 

fa.?. main  red. arty. fi res 

: Storage  requirement  is  constant.  Execution  time 
is  deoendent  on  the  product  of  salvos  and  tanks  in 
b1 ue.al i ve. 
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RELOAD 


NUMBER  BYTES  OBJECT  CODE  ; 2736 


PARAMETERS 


LOCAL  VARIABLES 


GLOBAL  VARIABLES 
bt  i me 
C.2 
case 
cdh 
cheat 
def num 
guntube 
p.con 
s2. t i me 


CALLED  BY 


SCHEDULES 


complexity 


: Constant  execution 

requi rements. 


NUMBER  BYTES  OBJECT  CODE  I 232 


GLOBAL  VARIABLES 
hnorm 


READS 


CALLED  BY 


complexity 


: Constant  execution 

requi rements* 


RES2 


NUMBER  BYTES  OBJECT  CODE  : 2000 


GLOBAL  VARIABLES  : 

accbm 

accke 

addon 

bushbmp 

ht  .mov 

lell 

)e31 

1a71 

leBl 

mi n1 eth 

tapdi m 


accht 
accms ) 
bm.fflov 
dgnv 
ke.inov 
1el2 
1 e61 
le72 
y}  e82 
sovmg 
usmg 


RESERVES 


accbm 

accke 

addon 

bushbmp 

ht •mov 

lell 

1e31 

le7l 

ledl 

m i n 1 e.t  h 

tapdi m 


accht 

accms 1 

bm .mov 

dgnv 

ke.mov 

1el2 

lebl 

1e72 

1ee3 

sovmg 

usmg 


CALLED  BY 


complexity  > Constant 
requi rements . 


execut i on 


t i me 


storage 


remarks  : Rearrangement  of  subscripts  will  provide 
efficient  storage  utilizing  fewer  pointers. 


RES3 

NUMBER  BYTES  OBJECT  CODE  ; 3336 


LOCAL  VARIABLES  : 


GLOBAL  VARIABLES  : 
tell 
te31 
Ie71 
teSl 


1 el2 
1e61 
1e72 
.1e83 


CALLED  BY  : 


complexity  : Constant  execution  time  and  storage 

reaui rements. 

remarks  : Rearranging  loops  to  avoid  duplication  will  cut 
the  number  of  "for"  looos  from  11  to  6. 

RESa 


LOCAL  VARIABLES 


NUMBER  BYTES  OBJECT  CODE  : 1°12 


GLOBAL  VARIABLES 
acch  t 
accms 1 
dgnv 
ke  ^mov 


accke 
addon 
ht .mov 
t ardi m 


CALLED  BY  : 


COMPLEXITY  t Constant  execution  time  and  storage 
requ i rements • 

REMARKS  : Combine  7 "for"  loops  with  i=l  to  2 into  1 loop. 


I 

f 


MICROCOPY  RESOLUTION  TEST  CH^ 

NATIONAL  BUREAU  OF  STAejOARD6'1963' 


I 


RES5 

. NUMBER  BYTES  OBJECT  CODE  : aS 

CALLED  BY  : 

main 

remarks  : This  routine  does  nothing* 

SECTOR, CHECK 

NUMBER  BYTES  OBJECT  CODE  : 608 


PARAMETERS  : 

/ 

a 

b 

LOCAL  VARIABLES  : 

a 

answer 

b 

c. 1 eft 

c. right 

r 

X .t 

y.t 

GLOBAL  variables  : 

area 

constant 

x.current 

y .current 

CALLS  : 

abs.f 

sort ,f 

CALLED  BY  : 

impact 

step.t i me 

complexity  : Constant 

storage  and  execution 

SET. MUZZLE. VEL 


NUMBER  BYTES  OBJECT  CODE  : aOO 

PARAMETERS  t 

a 

LOCAL  VARIABLES  : 

a 

GLOBAL  VARIABLES  t 
msi .vel 

CALLED  BY  t 

fire 

complexity  : Constant  storage  and  execution  time. 
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I 


parameters  : 

tank 

LOCAL  variables  : 

a 

tank 

X 

GLOBAL  VARIABLES  : 
pi  .c 


CALLS  : 


cos.  f 


SET. SECTOR 

NUMBER  BYTES  OBJECT  CODE  : a48 


CALLED  BY  : 

chg. sec. search 
di amount .dragon 
red. create 


b 

width 

y 


sin.f 


defend 
mai  n 


COMPLEXITY  : Constant  storage  and  execution  time. 

SIGHT 

NUMBER  BYTES  OBJECT  CODE  : 712 


PARAMETERS  : 

a 

b 

GLOBAL  VARIABLES  : 

bwd. 1 ook 

hto 

name 

pca. vi s 

pcb. vi s 

V .current 

CALLS  : 

1 os 

CALLED  BY  : 

commo.pass.tgt 
f i re 

step.time 


aname 

bname 


f wd. 1 ook 
micro 
pea .unc 
pcb.unc 
X .current 
z .current 


min.f 


detect 

impact 

target .sel ect 


complexity  : Constant  storage  and  execution  time. 


•J 
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STEP. TIME 


.NUMBER  BYTES  OBJECT  CODE  : 1664 


PARAMETERS  : 

a 


LOCAL  VARIABLES  : 


a 

answer 

bdat.t ime 

1 ose 

p 

rdet .time 

rn.b 

rn.r 

GLOBAL  variables  : 

✓ 

a1 i va.daad 

answer 

bwd. 1 ook 

def nuffl 

dal ta.t 

fa 

f .bl ua.al 1 va 

f wd. 1 ook 

nama 

OP. rng 

pcb.unc 

pet  • V 1 s 

stapa 

target 

tgtsc 1 

1 1 me. V 

w . k . c * 

K .current 

y .currant 

RESERVES  : 

1 i St 

RELEASES  : 

1 i St 

CALLS  : 

cardi o 

chg. sec .search 

di  sr 

mi  n.  f 

sactor .check 

sight 

t racer 

uni  form. f 

SCHEDULES  : 

detect 

step. t ime 

SCHEDULED  BY  : 

main 

step. time 

complexity  : Storage  Is  constant. 

Execution  time 

dependant  on  the  number 

of  tanks  In  red 
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1 i near 1 y 
H va. 


itiuiMuiam 


*1-  .'V-  xxg-.*'  *A  ' ^ I|>|» 


STOP. SIMULATION 

.NUMBER  BYTES  OBJECT  CODE  : aa96 


GLOBAL  VARIABLES  : 

attributes  of 
attributes  of 
attributes  of 
attributes  of 
attributes  of 
a1 i ve.dead 
awl .or.msi 3 
bc.eount 
c • 1 

CO 

def num 
f.d 

f i red.at 
he.drag 
k.hit 
1 in 

m. d 

mf .hi t 
mki  1 1 
name 

n. bl ue.al i ve 
nuffl.hi t 

pi  t 
r.con 
sec 
spd 

t i me. V 
t .spd 
X .current 
z. current 


every  fo 
every  battery 
every  fdc 

every  mission  in  msn. queue 
every  mission  in  holding.msns 
ap.tow 
bn 

'e.2 

erf 

di r .of .mvmt 
f .h  i t 
fki  1 1 
hi t .state 
kki  1 1 

m. h i t 
mfki 1 1 
mv. state 
nd.h i t 

n.  red.al i ve 
pi ow.cond 
pri .di r 

rc. count 

tank 

trf 

wpn.type 
y .current 


CALLS 


attributes  of 
attributes  of 
attributes  of 
attributes  of 
attributes  of 
a) i ve.dead 
awl .or .nsl 3 

be . count 
c.l 

CO 

def num 
f .d 

f i red.at 
he. drag 
k.hit 
Mn 

m. d 

mf .h  i t 
mk  i n 
name 

n. bl ue.al i ve 
num.h i t 

pi  t 
r.con 
sec 
sod 

t i me.v 
t .spd 
X. current 

z.  current 


loc 


STOP. SIMULATION  (cont) 


every  fo 
every  battery 
every  fdc 

every  mission  in  msn. queue 
every  mission  in  holding. msns 
ap.tow 
bn 

.e.2 

erf 

y 

di r .of .mvmt 
f .hi  t 
fki  1 1 

hit. state 
kki  1 1 

m. hi  t 
mf  k i 1 1 
mv .state 
nd.h i t 

n.  red.al i ve 
plow.cond 
pr i .dir 

rc .count 

tank 
t rf 

wpn.type 
y .current 


SCHEDULED  BY  : 

attri tion. check 


mai  n 


complexity  : Execution  time  is  linear  on  tanks  and  storage 
is  constant. 
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PARAMETERS  : 

a 


STOP. TO. FIRE. 

NUMBER  BYTES  OBJECT  CODE  : 368 

stopcount 


LOCAL 

VARIABLES  : 

a 

stopeount 

GLOBAL 

VARIABLES  : 

b1  ua 

color 

proio 

- saeond.shot 

sod 

t.spd 

^t  i ma  • V 

CALLED 

BY  : 

fire 

Impact 

: Constant  exacution 

reouf  ramants. 


complexity 


1 4 ma  and 


storaga 


SUBCAL 

NUMBER  BYTES  OBJECT  CODE  t 4040 


PARAMETERS 


f .pcvi s 

pc . vi  s 

r 

sh.t 

tgt  .t 

[ABLES  : 

efki 1 1 

efpi 

emki 1 1 

empi 

f .pcvis 

i 

io 

1 

jo 

kayki 1 1 

kavpi 

1 

mo 

n 

nhit 

pc.vi s 

phi  t 

r 

ro 

sh.t 

tgt.t 

vel 

whocal i ed 

llABLES  : 

bushbmp 

damage.num 

dgnv 

oh 

pro  jo 

sovmg 

spd 

tardim 

usmg 

wpn.type 

projo 

Mpn.type 

binomial . f 

bushbmp 

sovmg 

t rune  • f 

usmg 

• 

• 

compute 

HRITES  : 

CALLS  : 

CALLED  BY 


complexity  ; Execution  time  is  linear  on  nhit  and  storage  is 
constant • 


T72. TACTICS 


NUMBER  BYTES  OBJECT  CODE  : 1216 

PARAMETERS  : 


LOCAL  VARIABLES  : 


• 

aim 

answer 

1 ose 

rasul t 

X 

t i me 

GLOBAL  VARIABLES  : 

/ 

a1 1 ve»daad 

bwd. 1 ook 

chactc.tlme 

cocdr 

crl  tieal  •val  u» 

foe 

fwd»  loolc 

pet  .vi s 

pi tl dr 

projo 

ached 

' tank 

t \ me>a 

t i me.v 

CALLS  : 

. 

amno.checV 

commo.pass.tgt 

exp.f 

1 ay • 1 oad 

1 oc 

CALLED  BY 

e 

• 

— 

target  >301  act 

• 

SCHEDULES 

e 

e 

f 1 re 

complexity 

' r Execution  time  is 

1 i near  on  tank  i n 

pi t .uni t 

and  storage  requirements 

are  constant. 

REMARKS  : 

Returns  the  value 

of 

answer  to  the 

calling 

I 


TALLY. HIT. STATE 

NUMBER  BYTES  OBJECT  CODE  : 1856 


PARAMETERS  : 

danagcr.num 


tank 


LOCAL  VARIABLES  : 

damaga.num 


tank 


GLOBAL  VARIABLES  : 
b1  ua 


CO 

cofflp.uni t 
f .hit 
k.hi  t 

ffi.bl ua.at i va 
m.hi  t 
no.hi t 
pi  t 

rad.al i va 


b1 ua.ali va 
color 


f { red. at 
list 
mf  .h  i t 
name 
num.hi t 
pi t .uni t 
target 


REMOVES 


tank  from  blue. alive  or  red. alive*  pit. unit  and 
comp.uni t 


RELEASES  t 


list 


CALLS  : 


1 eave. check 


CALLED  BY  : 

final .death 


i mpact 


complexity  : Constant  execution  time  and  storage 

regui rements. 


i 


TARGET. SELECT  • 


NUMBER  BYTES  OBJECT  CODE  : 2592 


PARAMETERS  : 


LOCAL  VARIABLES 


o1 d. range 
P 

rnd 

whocal 1 ed 

GLOBAL  variables  : 

at i ve.dead 

bwd.took 

color 

def nun 

ftp 

fkt  1 1 

f wd. t ook 

Hat 

name 

pointer 

range 

target 

1 1 me.v 

* .current 


CALLS  : 


bmp. tactics 

di  St 
h i der 

itv. tactics 
1 i St  .update 

priori ty .and. round. set  ect 
t72. tactics 


SCHEDULES  : 

fire 

SCHEDULED  BY  r 

1 i St .update 
we. mi ss 


aim 

engaged 

id 

o1  dp 
r 

t i me 


blue 

check .time 
critical .value 
fa 

f i re 
foe 

1 ine. of. sight. exists 

mv. state 

pet  .vi s 

projo 

sched 

t i me . a 

wpn.type 

y .current 


di  m.  f 
exp.f 

{ fv. tactics 
1 ay . 1 oad 
1 oc 
sight 

xml . tact i cs 


we.hi t 


complexity  : Constant  storage  and  execution  time. 
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TRACER 


. NUMBER  BYTES  OBJECT  CODE  : 304 

PARAMETERS  : 

a 

LOCAL  VARIABLES  : 

a 


GLOBAL  VARIABLES  : 

time.v  tr.tima 

WRITES  : 

a Cima.v 


CALLED  BY  : 

arty • i moact 

busy»radio»net 

check { n9»guns .avaf 1 abi ) 

comfflo .at  tempt 

end.of  .mi  ss'i on 

f a.tgt .error 

f < re 

{ mpact 

new.coordi nate.system 
new.mi ssi on 
parameters 
red.arty .f i res 
update.c 1 uster 


arty. time 
ty 

detect 

error 

f dc .processing 
guns. f i ri ng 
mr] . i mpact 
new. 1 ocat i on 
open.radio.net 
posi t i on. update 
step.t ime 


complexity  : Constant  storage  and  execution  time. 
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LOCAL  VARIABLES  : 


GLOBAL  VARIABLES  : 


t ap.tow 

awl  .or.msl 3 

aw2.or.adm 

p.l 

^ C.2 

def num 

foe 

he. drag 

» hitshot 

mi ssshot 

* r.con 

1 Mpn.type 

1 CALLS  : 

• hider 

i . CALLED  BY  : 

impact 

r. count 

> SCHEDULES  : 

hide 

target .sel ect 

complexity  : Constant 

storage  and  execution  time 

ME. MISS 


NUMBER  BYTES  OBJECT  CODE  : 190S 

PARAMETERS  : 

a 


LOCAL  VARIABLES  : 


a 

answer 

r 

X 

time 

GLOBAL  VARIABLES  : 

ap.tow 

r awl .or .ms) 3 

aw2.or.adm 

c.  1 

e.2 

check • t i me 

def num 

foe 

he. drag 

hi tshot 

mi ssshot 

projo 

range 

r .con 

sched 

t i me.a 

t ime.v 

wpn.type 

X .current 

y .cur rent 

CALLS  : 

ammo. check 

di  St 

exp.f 

1 ay • 1 oad 

hi  der 

CALLED  BY 

e 

• 

i mpact 

SCHEDULES 

• 

• 

f i re- 
target .se?  ect 

h i de 

complexity  : Constant  storage  and  execution  time. 
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XMl. TACTICS 


NUMBER  BYTES  OBJECT  CODE  ; 352 


parameters  : 


LOCAL  VARIABLES 


GLOBAL  variables  : 
fo* 

pi C .uni t 


answer 

z 


pit 

tank  / 


CALLS  : 


uni form*f 


CALLED  BY  : 

target .sal  act 

complexity  ; Storage  is  constant.  Execution  is  linearly 
dependent  on  the  number  of  tanks  in  pit. unit. 


APPENDIX  C 


ROUTINE 


main 

hi  dar 

real 

res2 

res3 

rasfl 

pesS 

red. create 
b1 .create 
new. forces 
sight 

convert. back 

«* 

param.set 
basic. load 
val s. for. case 
reload 
bug. check 
dr .mount 
di amount .dragon 
df  .chg 
defend 
step. time 


LINES 

START 

END 

BYTES 

SIMSCRIPT  ROUTINES 

95 

ba026 

bb750 

5928 

10  . 

bb750 

/ 

bb890 

320 

3 

bb890 

bb978 

232 

24 

bb978 

be  148 

2000 

37 

bcl48 

bceSO 

3336 

16 

bceSO 

bd5c8 

1912 

2 

bd5c6 

bd5f8 

48 

43 

bd5f6 

bdf  60 

2408 

46 

bdf60 

bea68 

2824 

5 

bea68 

bebeS 

128 

9 

bebe8 

beebO 

712 

17 

beebO 

bf  178 

712 

21 

bf  178 

bf510 

920 

27 

bf510 

bfd38 

2068 

10 

bfd38 

cOOOO 

712 

40 

cOOOO 

cOabO 

2736 

12 

cOabO 

cOebO 

1024 

18 

cOebO 

C1356 

1192 

12 

C1358 

cl640 

744 

14 

cl640 

cl830 

496 

12 

C1830 

claeO 

668 

65 

c laeO 

c2660 

1664 

! 


7 


I 
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I 


I 


i 


I 


ROUTINE 

LINES 

START 

END 

BYTES 

detect 

21 

c2660 

C2978 

792 

target.sel eet 

7a 

c2978 

C3398 

2592 

f i re 

51 

c5398 

c3c50 

2232 

1 eave.cheek 

112 

c3c50 

C6278 

9768 

charge 

47 

C6278 

cbaeO 

2152 

get .UP 

12 

t:6ae0 

c6d20 

576 

impact 

84 

c6d20 

c7ea8 

4488 

loc.update 

6 

c7ea8 

C8028 

384 

stop.si mul at i on 

27 

c8028 

c90t0 

4296 

cardio 

55 

c90f0 

c95f0 

1280 

1 i St .update 

62 

c95f0 

c9d20 

1840 

proximt  ty. detect 

26 

c9d20 

ca080 

864 

commo.pass.tgt 

21 

ca080 

ca2b8 

488 

t72. tactics 

27 

ca2b8 

ca778 

1216 

Ifv. tactics  ^ 

9 

ca778 

Ca8(38 

352 

xml. tactics 

9 

ca6d8 

caa38 

352 

bmp.tacti cs 

6 

caa38 

cab40 

264 

1 tv. tactics 

9 

cab40 

cacaO 

96 

set .muzzt  e.vel 

8 

cacaO 

cae30 

400 

priori ty. and .round. select 

49 

cae30 

cb368 

1336 

ammo. check 

11 

cb368 

cb558 

496 

decrement .ammo 

13 

cb558 

cb858 

768 

we.ml ss 

39 

cb858 

cbf  b8 

1808 

we.h  1 1 

28 

cb^b8 

cc4e8 

1328 

stop. to. f1 re 

13 

cc4e8 

cc658 

368 

lay. load 

35 

cc658 

ccea8 

2136 

3 


j 


\ 


1 

\ 


i 


I 
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I 


I 

r 

k 

r 

< 

I 


I 

i 


ROUTINe 

LINES 

START 

END 

BYTES 

first 

S 

cceaS 

ccfc8 

288 

hid* 

23 

ccfc8 

cd4c8 

1536 

loc 

23 

cd4c8 

cd9l0 

1096 

chg.s«c.s«arch 

25 

cd910 

Cde28 

1304 

tai 1 y .hi t .stat* 

43 

cde28 

ce566 

1856 

di  St 

4 

ce568 

ceSf  8 

144 

sat .sector 

12 

ce5f8 

ce7b8 

448 

sector. check 

10 

ce7b8 

eeal8 

608 

attri tion. check 

7 

ceal8 

cec08 

496 

compute 

91 

cec08 

cf9c8 

3528 

geom 

ISO 

cf9c8 

dl958 

8080 

subeal 

79 

dl958 

d2720 

4040 

at  r i t 

43 

d2720 

d2f  fO 

2256 

pop.a.mi ne 

20 

d2ff0 

d36d0 

1760 

final .death 

14 

d36d0 

dic60 

1424 

fa. 1. main 

83 

d3c60 

d4fa8 

4936 

fa. 2. main 

44 

d4fa8 

d5d38 

3472 

f o.not .busy 

9 

dSd38 

dSfdO 

408 

update.c 1 uster 

46 

dSfdO 

d64a0 

2256 

commo.attempt 

26 

d64a0 

d68e8 

1096 

open.radio.net 

6 

d68e8 

d69d8 

240 

bu8y.radio.net 

6 

d69d8 

d6ac8 

240 

f dc .proeessi ng 

110 

d6ac8 

d7828 

3424 

cheek ing. guns. avai lability 

37 

d7828 

d7f48 

1824 

guns.fi  ring 

34 

d7f48 

d8630 

1768 

arty . impact 

132 

d8630 

d9b50 

1312 
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7 

ROUTINE 

LINES 

START 

. END 

■1 

i 

1 

BYTES  ! ^ 

* 1 , 

end.of .ml ss{ on 

59 

d9b50 

da5e0 

270a 

doing.clustcrs 

assessment 

i 

114 

da5e0 

db998 

5048  ^ 

95 

db998 

dcb48 

4528 

error 

28 

dcb48 

dcef8 

944 

- 

f red.arty.f < res 

75 

dcef  6 

ddc20 

3368 

neM.coordI nate* system 
fc 

8 

^dc20 

dddl8 

88  j 

new. mission 

f 

27 

dddl8 

de2b0 

1432  1 ^ 

parameters 

53 

de2b0 

de718 

1128 

arty. time 

24 

de718 

de8b8 

416  1 

^ fa. tgt. error 

21 

de8b8 

dea56 

416 

new. location 

54 

des58 

def  cO 

1384 

mr 1 • impact 

53 

def  cO 

df9c8 

2568  i 

^ preplanned 

31 

df9c8 

dfdbS 

1008  ; 

posi t ion. update 

29 

dfdb8 

e0208 

1104 

1 print 

10 

e0208 

e0358 

336 

printl 

22 

e0358 

e0840 

1124 

tracer 

8 

e0840 

e0970 

304 

. new.fo 

i 

r 

8 e0970 

FORTRAN  ROUTINES 

e0b38 

456 

move 

r 

145 

e4ce8 

eS860 

4048 

i i n i t rd 

73 

e0el8 

el688 

2414 

1 ’ setup 

1 

1 os 

■ 

53 

e70b8 

e7508 

1300 

251 

e3260 

e4c86 

7504 

J kover 

14 

ee220 

ee3f0 

684 

el  ev 

33 

e2ea0 

e31  aO 

988 

1 

dy tunx 

31 

ef  al8 

ef  aaO 

1138 

1 ^ ''  ' — ' — ^ 

■f. 
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. ^ 


ROUTINE 

LINES 

START 

. END 

BYTES 

• levg 

36 

••be6 

•®f7S 

1132 

. 

• 

mcov 

24 

•2b66 

•2dd6 

666 

PROGRAM  TOTALS 

3642 

ba02S 

✓ 

Il77e0 

362404 

i 

! 

i 

I 

I 


} 

\ 


I 
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(*/a)  6566  533a 


TYPE  NOS  PTR3  OPT  REMARK  TOTAL  OPTIMAL 


ROUTINE 


c*b«r 


d.num 


pea.vi  s 

pcb.unc 

pcb.vi  s 

pca.unc 

p.v 

ih 

Hat 

target 

temp, target 

del 

ds2 

t .dead 
i .dead 
i t .dead 


96a  6a5 


376  376 


372  372 


(*/a) 


(*/a) 


(*/aj 


3675  2911 
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